Replies: 1 comment
-
Here's an example of how it can be done(generally, it's exactly what you have done, but an "official" version)
CKAN stores ready-to-use application under As for config files, it's better to use the same config file for all the interactions with the CKAN instance. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
For the project I'm working on, it has a small set of CLI commands beneath our main project plugin. I'm converting the commands from Pylons to Click. One command makes some changes that trigger another plugin's methods -- IPackageController.before_search. When calling the command, I'm providing it the same config file used to run the CKAN site process.
While testing, the command failed with a RuntimeError: "working outside of application context" when before_search on the other plugin was called. The other plugin checks Flask's global g for certain attributes in its before_search implementation.
I resolved the problem as follows:
Are there any suggestions for possibly more appropriate ways to avoid Flask/CKAN losing its context when other methods or plugins execute for command-line operations?
Is it often better to use a separate config file than the main site's config? I believe that was how we resolved an issue between plugins for this set of commands when using Pylons -- we provided a separate, Paster-specific config with certain plugins removed.
Beta Was this translation helpful? Give feedback.
All reactions