[#2842] New CKAN config object, decoupled from Pylons #3163
This PR includes a bunch of changes that provide a common configuration object for CKAN that works both on Flask and Pylons.
Both Flask and Pylons config objects are dict-like objects with key/value configuration options. But the Flask one is bound to the application and so it's only available when there is an application context available. This means that it can not support the way in which we were using the Pylons config, which was essentially available everywhere, on the CLI, tests, etc. In order to not change completely the way the application is structured and how the configuration is accessed in all parts of the code it seemed a good approach to have our own dict-like config object that was available in the same way the Pylons config object is.
At the same time we don't want to have different sets of configurations for stuff relevant to CKAN, Flask or Pylons (eg
Moving forward this should be the only configuration object used in all code unless we really
Extensions should be encouraged to use
The text was updated successfully, but these errors were encountered:
Call `load_environment` before making both stacks rather than from the Pylons one. Call the app_globals code on the common environment code, not just on the Pylons stack. Update the Flask config object with all the CKAN values. Don't pass explicitly the configuration object to the `load_all` plugins function, use the one in common.
On this particular branch this is needed so the common CKAN config object can forward config options to the Flask app config object, but this will be required anyway as more Flask features need to be available during a Pylons request (see 62f55d2).
Rather than rely on the Pylons (or Flask) config object we define our own in ckan.common. This is a dict-like object (so fully backwards compatible) that also proxies any changes to the Flask and Pylons configuration objects (if they are available) This should be the only configuration object used in all code unless we really need to access the underlying Flask or Pylons objects for some reason. The `ckan.common.config` instance is initialized in the `load_environment` method with the values of the ini file or env vars. This is actually a proxy to a property from a Werkzeug Local object, meaning that `config` is thread-local safe, like its Flask and Pylons counterparts. See http://werkzeug.pocoo.org/docs/0.11/local/ I tried to separate all Pylons specific stuff (things like `pylons.paths`, `routes.map` etc) to Pylons own config object to keep the main config object clean but it proved too difficult, not only because we access these keys from different parts of the code (which can be solved) but also because when clearing the config (done on the tests) we lose keys that were added on `load_environment` and we would need to keep track of those.