Don't offer to upgrade plugins installed outside of user profile

[nyalldawson]

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!)

[github-actions]

🪟 Windows builds ready!

Windows builds of this PR are available for testing here. Debug symbols for this build are available here.

(Built from commit 87151f5)

[Gustry]

Is the user still aware of its "outdated" copy ? (to let him aware that he is not running the latest version anymore)
It looks like it will go in the "Installed" tab ? IMHO, it should still go in the "upgradeable" tab.

This was very wanted for PyQGIS devs, thanks

[nyalldawson]

IMHO, it should still go in the "upgradeable" tab.

That'd be rather confusing -- an upgradable plugin which can't be upgraded? 🙃

[Gustry]

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 :

If a user is in a setting where plugins are installed in a centrally managed location

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.

If a developer has symlinked a plugin to a local dev copy of that plugin

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.
After creating my branch, and fixing the bug, I'm waiting for the merge and the new release of the version. Then I'm might not use git anymore for this plugin so I won't be aware a new version is available of this plugin ?

[nyalldawson]

@Gustry

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?

[Gustry]

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.
It depends of my level of contribution on this plugin in a near future :) (active contributor for my work, or just a bug I got one day, like the one on FirstAid plugin I mentioned above)

[github-actions]

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

• that all unit tests are passing

• that all comments by reviewers have been addressed

• that there is enough information for reviewers, in particular

  • link to any issues which this pull request fixes

  • add a description of workflows which this pull request fixes

  • add screenshots if applicable

• that you have written unit tests where possible
  In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this pull request.
  If there is no further activity on this pull request, it will be closed in a week.