-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't offer to upgrade plugins installed outside of user profile #57466
base: master
Are you sure you want to change the base?
Conversation
Is the user still aware of its "outdated" copy ? (to let him aware that he is not running the latest version anymore) This was very wanted for PyQGIS devs, thanks |
If a plugin is located outside of the user's default profile plugin install location, don't offer upgrades for that plugin to the user. (This affects only plugins which are symlinked into a profile from outside of the user's profile) There's two reasons why this is not desirable: - If a user is in a setting where plugins are installed in a centrally managed location, then an individual user should not be allowed to update these plugins - If a developer has symlinked a plugin to a local dev copy of that plugin, then updates should not be offered (and allowing the user to update would risk wiping out changes in that dev's local copy!)
That'd be rather confusing -- an upgradable plugin which can't be upgraded? 🙃 |
But the plugin is some how upgradable. It's not just using the normal way, with the QGIS plugin manager. I was thinking more to show them in the "Upgradable" tab, but the button to upgrade disabled with an information :
People from the GIS service won't be able to know/notice a new version is available, and they might not let the IT service aware that a new version is needed after a few months. I would rely on the IT service to follow plugins version.
I'm doing this as well. Even for some plugins where I'm not an active contributor at all, just to fix a bug I got on one plugin I used once in a year. I'm not an active contributor on FirstAid plugin for instance, but I made a PR to fix one bug wonder-sk/qgis-first-aid-plugin#43 with a symlink. |
I get what you're saying, but it would require quite a substantial refactor of the plugin manager to add a new state for upgradeable-but-blocked-from-upgrade, and I'm not comfortable doing that given the the current state of the plugin manager code (and lack of tests). So the question would be whether we just close this as a "wontfix" or accept it as an incremental improvement? |
Thanks for taking care of my comments. I know the current status of QPM... It's little bit tricky... Which use case did you want to cover first ? Plugin deployment within organization or git ? In case of git, is it possible to check what you have done in this PR when the installation is done by QPM, and add a QMessageBox question if the plugin is symlinked to know if we continue ? Depending on the plugin, I either upgrade from GIT, or I let QGIS erasing my previous symlink. |
The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check
|
If a plugin is located outside of the user's default profile plugin install location, don't offer upgrades for that plugin to the user.
(This affects only plugins which are symlinked into a profile from outside of the user's profile)
There's two reasons why this is not desirable: