Pip install missing dependencies

[axelande]

Feature description.
Would it be possible to make it possible for the user to install external plugins here? Instead of embed code similar to the proposed code in each plugin that require external plugins it would be nice to let the user to "pip install" them without forcing them to open the osgeo4w shell and trying to get that to work (which it seldom do for me unless I write c:\osgeo4w\apps\python37\python.exe c:\osgeo4w\apps\python37\Scripts\pip.exe install package_x)

Additional context
I'm proposing a button ("Install from pypi") and an option with functionality similar to this:

def install_external_package(self, package_name):
        try:
            import package_name
        except ModuleNotFoundError:
            if platform.system() == 'Windows':
                subprocess.call([sys.exec_prefix + '/python', "-m", 'pip', 'install', 'package_name'])
            else:
                subprocess.call(['python3', '-m', 'pip', 'install', 'package_name'])
            try:
                import package_name
                return True
            except ModuleNotFoundError:
                return False

[Gustry]

Are you talking about https://docs.qgis.org/testing/en/docs/pyqgis_developer_cookbook/plugins/plugins.html#plugin-metadata and search for plugin_dependencies ? There isn't a button. This is reading the metadata file.

http://changelog.qgis.org/en/qgis/version/3.8/#plugin-dependencies-optional-support

[axelande]

Yes, I would like to have a button here to get the option to install the external plugins from pypi here.

[axelande]

I understand that this plugin_dependencies refers to other plugins uploaded to plugins.qgis.org

What I'm asking for is to extend this functionality to also include other external python packages from pypi.org is this a bad idea or shall I try to make a pull request on it?

[roya0045]

I'm pretty sure such an approach is bound to lead to dependencies issues and broken plugins if it were to be implemented.

[elpaso]

This has been discussed a few times in the past years, IIRC the main problems were:

1. there is no reliable cross-platform way to run pip as a library (subprocess is even less reliable)
2. a plugin may require a particular version of a dependency

the recommended solution (proven to be effective in large corporate deployments) is to ship the dependencies with the plugin and make sure the modules are namespaced or renamed in order to avoid conflicts with modules with the same name loaded by other plugins.

Another approach that has been discussed and that would probably be the best one is to create a separate virtual env for each plugin, but given the fact the we are calling python from C++ code we are probably bound to a single interpreter instance that shares all memory and modules.

But please don't be discouraged and if you find a nice solution it will be more than welcome.

[goatchurchprime]

There's a similar problem over at FreeCAD, which is also a monolithic Python/C++/QT/plugins hybrid application. https://forum.freecadweb.org/viewtopic.php?f=10&t=43095

If the problem is caused by a lack of quality control on what gets into the pypi system, one could either (a) bring a few more of the most needed python modules into the core system, or (b) maintain a list of modules that the plugin installer is allowed to pull in before the plugin must be tagged as "experimental".

The module I'm most keen on using in FreeCAD is ezdxf, which is very good, and might be of some use to QGIS too. So maybe we just need a list of the non-problematic external modules on the basis of some criteria (eg pure python, no filesystem access outside of the tmp directory, and no subprocess.call() commands). We could either share this list between the projects that need it, or lobby for it to be a standard tag that we can use in the pypi system.

[github-actions]

The QGIS project highly values your report and would love to see it addressed. However, this issue has been left in feedback mode for the last 14 days and is being automatically marked as "stale".
If you would like to continue with this issue, please provide any missing information or answer any open questions. If you could resolve the issue yourself meanwhile, please leave a note for future readers with the same problem and close the issue.
In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this issue.
If there is no further activity on this issue, it will be closed in a week.

[alexbruy]

Duplicates #18693