Nyall Dawson <nyall.daw...@gmail.com> writes: > I would personally feel safest if this was something officially endorsed, > with an explicit allow list of acceptable packages.
This is my reaction, too, of having a curated list of packages that could be installed, with the list managed by qgis, perhaps in the regular sources, perhaps fetched (signed?) from qgis.org. Training users to click to download/install additional software isn't in my view a great path, even if the intent behind the request is honorable. There's a larger issue, which is that downloading and installing things is not consistent with package management systems. Plugins are already a bit like that, but generally are just python without additional dependencies. There is a regrettable trend for every environment and language implementation to invent its own packaging system. To me, the preferred path is to have a list of what's required, with the expectation that they are available in packaging systems, and to have the user install packages. That's how it would be if a plugin were packaged. And, for a python module that needs a C library as a dependency, or a Fortan compiler or something, it doesn't really work to just ask via pip. It's possible that if particular python libraries are needed relatively often they should become formal dependencies of qgis, or in a qgis-plugin-support package that can be installed. _______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer