Migration from Pylons to Flask¶
On CKAN 2.6, work started to migrate from the Pylons web framework to a more modern alternative, Flask. This will be a gradual process spanning multiple CKAN versions, where both the Pylons app and the Flask app will live side by side with their own controllers or blueprints which handle the incoming requests. The idea is that any other lower level code, like templates, logic actions and authorization are shared between them as much as possible. You can learn more about the approach followed and the work already done on this page in the CKAN wiki:
This page lists changes and deprecations that both core and extensions developers should be aware of going forward, as well as common exceptions and how to fix them.
Always import methods and objects from the plugins toolkit if available¶
This is a good practice in general when writing extensions but in the context of the Flask migration it becomes specially important with these methods and objects:
from ckan.plugins.toolkit import url_for, redirect_to, request, config url_for() redirect_to() request config
The reason is that these are actually wrappers provided by CKAN that will proxy the call to the relevant Pylons or Flask underlying object or method depending on who is handling the request. For instance in the config case, if you use pylons.config directly from your extension changes in configuration will only be applied to the Pylons application, and the Flask application will be misconfigured.
config was added to the plugins toolkit on CKAN 2.6. If your extension needs to target CKAN versions lower and greater than CKAN 2.6 you can use ckantoolkit <https://github.com/ckan/ckantoolkit>, a separate package that provides wrappers for cross-version CKAN compatibility:
from ckantoolkit import config