Plugin dependencies followup: load dependent plugins after their dependencies on QGIS startup #44906
Conversation
This file contains 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
…ndencies on QGIS startup
…PythonUtils->pluginList(), which will be the order used to load Python plugins to QGIS
gacarrillor
force-pushed
the
plugin_dependencies_follow_up
branch
from
9e55891
to
897e636
Compare
…t plugins by dependencies
elpaso
approved these changes
Sep 5, 2021
nyalldawson
reviewed
Sep 6, 2021
gacarrillor
added a commit
to gacarrillor/qpip
that referenced
this pull request
Aug 8, 2024
Since qgis/QGIS#44906, all dependent plugins will be loaded after their dependencies.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
PR #9619 introduced Python plugin dependencies to QGIS. Besides plugin installation, QGIS should handle dependencies also on QGIS startup, which is currently missing.
This PR is a followup to make sure dependent plugins are only loaded once their dependencies are loaded. Think about a modular plugin that can be extended by other plugins of the same company, depending on the clients. In such a use case, dependent plugins could add new buttons to the main (and independent) plugin's toolbar/menu. For doing so, dependent plugins require the independent plugin to be not only installed first (addressed already by Alessandro P.), but also loaded first on QGIS startup.
The only significant change introduced by this PR is sorting the plugin list that QGIS traverses to load Python plugins. So, for instance, we won't deal with installed but disabled (aka. 'unavailable') plugins, which will need to be handled by plugin devs. Additionally, plugin unload shouldn't be an issue, because in the worst case (i.e., the independent plugin is unloaded first), independent plugins could emit a signal to inform their dependent plugins they'll have to live alone (or simply be unloaded as well) from that moment on. Therefore, plugin unload is not addressed in this PR, as in my opinion can be left to plugin devs.
As it is, this PR will also work for
qgis_processand, as far as I know, forqgis_serverplugins (although I'm not sure if the server supports plugin dependencies as well), which also traverse themPythonUtils->pluginList()to load plugins.Since QGIS code calls
updateAvailablePlugins()from several parts, but only one of those needs the plugin list sorted, I ensured we only ask for a sorted list when loading plugins, and the other calls remain getting the original (unsorted) plugin list.Several unit tests were added, for both C++ and Python.
@elpaso, since you implemented the basis for plugin dependencies, and I'm moving one of your methods, I'd acknowledge if you can have a look at this PR.
Funded by SwissTierras-Colombia.