[#2842] New CKAN config object, decoupled from Pylons#3163
Merged
Conversation
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.
Conflicts: ckan/config/middleware/flask_app.py ckan/config/middleware/pylons_app.py
This was referenced Jul 13, 2016
| # update the config with the updated admin_tabs dict | ||
| config.update({config_var: admin_tabs_dict}) | ||
|
|
||
| # import ipdb; ipdb.set_trace() |
|
Looks excellent to me. |
Contributor
|
Looks good to me too. |
This was referenced Aug 8, 2016
Member
Author
|
See also ckan/ckantoolkit#5 for extensions that want to support multiple CKAN versions |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR includes a bunch of changes that provide a common configuration object for CKAN that works both on Flask and Pylons.
Summary:
pylons.configtockan.common.config(These are the bulk of the changes in a77ff9c)configto the plugins toolkit (37ecbe8)Discussion:
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
ckan.site_url,PROPAGATE_EXCEPTIONSorpylons.app_globalsrespectively). The CKAN config objects proxies any changes to the Flask and Pylons config objects (if they are available) so you can still configure all three applications using the same ini file (or env vars).Moving forward 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.
Extensions should be encouraged to use
toolkit.config(orckantoolkit.config, PR incoming).