How to get Registry().settings during Pyramid app startup time?

Question

I am used to develop web applications on Django and gunicorn.

In case of Django, any application modules in a Django application can get deployment settings through django.conf.settings. The "settings.py" is written in Python, so that any arbitrary settings and pre-processing can be defined dynamically.

In case of gunicorn, it has three configuration places in order of precedence, and one settings registry class instance combines those.(But usually these settings are used only for gunicorn not application.)

1. Command line parameters.
2. Configuration file. (like Django, written in Python which can have any arbitrary settings dynamically.)
3. Paster application settings.

In case of Pyramid, according to Pyramid documentation, deployment settings may be usually put into pyramid.registry.Registry().settings. But it seems to be accessed only when a pyramid.router.Router() instances exists. That is pyramid.threadlocal.get_current_registry().settings returns None, during the startup process in an application "main.py".

For example, I usually define some business logic in SQLAlchemy model modules, which requires deployment settings as follows.

myapp/models.py

from sqlalchemy import Table, Column, Types from sqlalchemy.orm import mapper from pyramid.threadlocal import get_current_registry from myapp.db import session, metadata  settings = get_current_registry().settings  mytable = Table('mytable', metadata,     Column('id', Types.INTEGER, primary_key=True,)     (other columns)... )  class MyModel(object):     query = session.query_property()     external_api_endpoint = settings['external_api_uri']     timezone = settings['timezone']      def get_api_result(self):         (interact with external api ...)  mapper(MyModel, mytable) 

But, "settings['external_api_endpoint']" raises a TypeError exception because the "settings" is None.

I thought two solutions.

• Define a callable which accepts "config" argument in "models.py" and "main.py" calls it with a Configurator() instance.

  myapp/models.py

  from sqlalchemy import Table, Column, Types from sqlalchemy.orm import mapper from myapp.db import session, metadata  _g = globals() def initialize(config):     settings = config.get_settings()     mytable = Table('mytable', metadata,         Column('id', Types.INTEGER, rimary_key = True,)         (other columns ...)     )     class MyModel(object):         query = session.query_property()         external_api_endpoint = settings['external_api_endpoint']          def get_api_result(self):             (interact with external api)...      mapper(MyModel, mytable)     _g['MyModel'] = MyModel     _g['mytable'] = mytable 

• Or, put an empty module "app/settings.py", and put setting into it later.

  myapp/__init__.py

  from pyramid.config import Configurator from .resources import RootResource  def main(global_config, **settings):     config = Configurator(         settings = settings,         root_factory = RootResource,     )     import myapp.settings     myapp.setting.settings = config.get_settings()     (other configurations ...)     return config.make_wsgi_app() 

Both and other solutions meet the requirements, but I feel troublesome. What I want is the followings.

• development.ini

  defines rough settings because development.ini can have only string type constants.

  [app:myapp] use = egg:myapp env = dev0 api_signature = xxxxxx 

• myapp/settings.py

  defines detail settings based on development.ini, beacause any arbitrary variables(types) can be set.

  import datetime, urllib from pytz import timezone from pyramid.threadlocal import get_current_registry  pyramid_settings = get_current_registry().settings  if pyramid_settings['env'] == 'production':     api_endpoint_uri = 'http://api.external.com/?{0}'     timezone = timezone('US/Eastern') elif pyramid_settings['env'] == 'dev0':     api_endpoint_uri = 'http://sandbox0.external.com/?{0}'     timezone = timezone('Australia/Sydney') elif pyramid_settings['env'] == 'dev1':     api_endpoint_uri = 'http://sandbox1.external.com/?{0}'     timezone = timezone('JP/Tokyo') api_endpoint_uri = api_endpoint_uri.format(urllib.urlencode({'signature':pyramid_settings['api_signature']})) 

Then, other modules can get arbitrary deployment settings through "import myapp.settings". Or, if Registry().settings is preferable than "settings.py", **settings kwargs and "settings.py" may be combined and registered into Registry().settings during "main.py" startup process.

Anyway, how to get the settings dictionay during startup time ? Or, Pyramid gently forces us to put every code which requires deployment settings in "views" callables which can get settings dictionary anytime through request.registry.settings ?

---

EDIT

Thanks, Michael and Chris.

I at last understand why Pyramid uses threadlocal variables(registry and request), in particular registry object for more than one Pyramid applications.

In my opinion, however, deployment settings usually affect business logics that may define application-specific somethings. Those logics are usually put in one or more Python modules that may be other than "app/init.py" or "app/views.py" that can easily get access to Config() or Registry(). Those Python modules are normally "global" at Python process level.

That is, even when more than one Pyramid applications coexist, despite their own threadlocal variables, they have to share those "global" Python modules that may contain applicatin-specific somethings at Python process level.

Of cause, every those modules can have "initialize()" callalbe which is called with a Configurator() by the application "main" callable, or passing Registory() or Request() object through so long series of function calls can meet usual requirements. But, I guess Pyramid beginers (like me) or developers who has "large application or so many settings" may feel troublesome, although that is Pyramid design.

So, I think, Registry().settings should have only real "thread-local" variables, and should not have normal business-logic settings. Responsibility for segregation of multiple application-specific module, classes, callables variables etc. should be taken by developer. As of now, from my viewpoint, I will take Chris's answer. Or in "main" callable, do "execfile('settings.py', settings, settings)" and put it in some "global" space.

Answer 1

Another option, if you enjoy global configuration via Python, create a settings.py file. If it needs values from the ini file, parse the ini file and grab them out (at module scope, so it runs at import time):

from paste.deploy.loadwsgi import appconfig config = appconfig('config:development.ini', 'myapp', relative_to='.')  if config['env'] == 'production':     api_endpoint_uri = 'http://api.external.com/?{0}'     timezone = timezone('US/Eastern') # .. and so on ... 

'config:development.ini' is the name of the ini file (prefixed with 'config:'). 'myapp' is the section name in the config file representing your app (e.g. [app:myapp]). "relative_to" is the directory name in which the config file can be found.

Answer 2

The pattern that I use is to pass the Configurator to modules that need to be initialized. Pyramid doesn't use any global variables because a design goal is to be able to run multiple instances of Pyramid in the same process. The threadlocals are global, but they are local to the current request, so different Pyramid apps can push to them at the same time from different threads.

With this in mind, if you do want a global settings dictionary you'll have to take care of that yourself. You could even push the registry onto the threadlocal manager yourself by calling config.begin().

I think the major thing to take away here is that you shouldn't be calling get_current_registry() at the module level, because at the time of import you aren't really guaranteed that the threadlocals are initialized, however in your init_model() function if you call get_current_registry(), you'd be fine if you previously called config.begin().

Sorry this is a little convoluted, but it's a common question and the best answer is: pass the configurator to your submodules that need it and allow them to add stuff to the registry/settings objects for use later.