Bug report #5879
running from build directory - no python plugins
|Affected QGIS version:||master||Regression?:||No|
|Operating System:||Easy fix?:||No|
|Pull Request or Patch supplied:||Yes||Resolution:|
|Crashes QGIS or corrupts data:||No||Copied to github as #:||15338|
When developing qgis, much time can be saved by running from the build directory, bu the core plugins are missing because they are not present in the build dir.
Perhaps a new "make install-dev" Makefile command could copy the plugins and also other missing things?
Also related, "imports should be moved into classFactory() so that nothing
happens unless the plugin is explicitly started".
Quoting Martin Dobias
- when QGIS is run from build directory, it doesn't copy the internal python plugins to the build output directory - that's why sextante is complaining about missing plugin installer. We should probably fix that in order to provide an environment that is as similar to the installed one as possible - the imports should be moved into classFactory() so that nothing happens unless the plugin is explicitly started. (this problem will go away once we stop using metadata from __init__.py and only use them from metadata.txt)
#2 Updated by Sandro Santilli almost 8 years ago
- Pull Request or Patch supplied changed from No to Yes
#3 Updated by Sandro Santilli almost 8 years ago
Alright, I confirm things work with those two pulls above. I can get db_manager loaded from output dir.
Next stop will be installing all plugins under output/
Ideally we'd have a macro for this on the CMake side, as the db_manager install has been very tedious....
Anyway please pull those two branches so I can get back to db_manager hacking when I find the time :)
#4 Updated by Sandro Santilli almost 8 years ago
I was thinking about two other possible ways to fix this:
1. Have the build dir listed in sys.path and plugin_paths, and make sure all sources are also copied to build dir
2. Have both the build dir and the source dir listed in sys.path and plugins_path
The second option would make the support automatically available to all plugins with no need to maintain anything at the plugin-level.
#10 Updated by Larry Shaffer almost 8 years ago
- Status changed from Open to Feedback
A current issue regarding the loading of plugins (while running from the build directory) is when plugins are restored on launch of the app. There is currently a goofy fix for this with commits e31fb3c9 and commit: where QgsApplication::pkgDataPath() is temporarily set to something other than QgsApplication::buildSourcePath() when restoring core plugins.
The reason for that patch: when QgsPluginRegistry::restoreSessionPlugins() is called the Python packages are imported from QgsApplication::buildSourcePath()/python/plugins even though that path is NOT in sys.path for the interpreter. If QgsApplication::pkgDataPath() is pointed to something other than QgsApplication::buildSourcePath(), or an empty QString, it works. However, I could find no means by which the interpreter was assigned that module search path.
I have tried:
- changing the current working directory in C++ and via Python
- setting PYTHONPATH
- setting all kinds of debug output from the interpreter (never shows buildSourcePath()/python/plugins in sys.path)
- giving up <-- that kinda worked
To reproduce the issue, run QGIS from the build directory and then launch DB Manager core plugin. You will get an error about a missing ui_*.py file, because that 'compiled' version of a *.ui file does not exist in source directory, only in the
build/output/python/plugins staged version of the plugin.
Now, run QGIS again, but with the
--noplugins option. This will keep
restoreSessionPlugins() from being called. After using Plugin Manager to turn back on DB Manager, launch the plugin and you should not get the error: sys.path is being honored, and the plugin is imported from
build/output/python/plugins staged area, as expected.
While the current patch works, it requires core plugins to not request QgsApplication::pkgDataPath() when the plugin loads. A better solution is needed.