Initializing the Application Configuration

If you are running the application from any entry point other than the normal paster serve, you'll need to initialize the configuration before you can use it. Make the following calls to do so:

1
2

conf = paste.deploy.appconfig('config:' + path_to_ini_file)
myapp.config.environment.load_environment(conf.global_conf, conf.local_conf)

The first line uses Paste to parse the INI file and initialize the configuration. The second passes the [DEFAULT] and [app:main] sections of the INI file to the load_environment function that the Pylons skeleton sets up for you. You can look inside config/environment.py to see what's happening there or override specific settings.

When run as a webapp, the Pylons skeleton handles the above portions for you. The appconfig call occurs within the Paste framework, and then the config fragments are passed to myapp.config.middleware.make_app() to initialize the application. The call to load_environment is the first line of make_app(). Check out config/middleware.py for details.

Accessing configuration information

Once the configuration has been initialized, there are several possible ways to access it.

Through the pylons.config object

Pylons has a global pylons.config object that is effectively a dictionary containing the contents of the INI file, along with any special fields you set in config/environment.py. You can use it simply by import pylons.config:

1
2
3

from pylons import config

my_option = config['my.config.option']

This would reference the my.config.option key inside the [app:main] section of the config file. All keys inside both sections are directly accessible as fields of the config object; in addition, the sections themselves are stored as app_conf and global_conf.

pylons.config is actually an instance of pylons.configuration.PylonsConfig, and has all the additional fields documented there.

The config object has a getattr handler that lets you access fields directly through dotted notation, instead of always treating it as a dictionary. This usage is deprecated, however.

In a config value, %(here)s expands to the path of the directory containing the file. This is useful to specify a path relative to the config file (e.g., %(here)s/my_file.txt). If for some reason you can't do that, you can resolve a relative path dynamically thus:

1
2
3
4

import os, pylons
config_file_path = pylons.config['__file__']
base_dir = os.path.dirname(config_file_path)
my_path = os.path.join(base_dir, my_relative_path)

However, it's usually better to specify the path in the config file using the %(here)s shortcut.

Through the WSGI environ dictionary

The config object is also available as the paste.config field on the WSGI environment, which can be accessed through the Pylons request object.

1
2
3

from pylons import request
environ = request.environ
my_global_value = environ["paste.config"]["global_conf"]["my.config.key"]

This works only when a request is active, so inside a controller method or something it calls (directly or indirectly).

In the base controller's ._call_() method

The WSGI environment is passed into the _call_ method of WSGI controllers, and so can be accessed directly there.

1
2
3
4
5

def __call__(self, environ, start_response):
    # Dict of the "[app:main]" section in your config file.
    cfg = environ["paste.config"]["app_conf"]      
    self.my_config_value = cfg["my.config.key"]
    ...

By setting a 'self' variable, all controller methods have easy access to the value.

Paste CONFIG object

This was the normal way to access the config in Pylons 0.9.5 and earlier, but is now deprecated.

1
2

from paste.deploy import CONFIG
my_config_value = CONFIG["app_conf"]["my.config.key"]

This also works only inside a controller method or something it calls. You shouldn't need to do this if you have access to the Pylons config object.

In websetup.py

The websetup.py generated by Pylons should have included calls to initialize the configuration in setup_config(). Make sure that you place any statements that are dependent upon it after those calls. Also, the WSGI methods of accessing the configuration will not work.