[QGIS-Developer] Understanding plugin dependencies (and plugins.xml)

[Sebastian M. Ernst]

Hi all,

still working on plugin management, I came across another question
regarding meta data.

Plugins can have "plugin dependencies" as detailed in the change log for
3.8:
https://qgis.org/en/site/forusers/visualchangelog38/#feature-support-for-plugin-dependencies

The name of the field in `metadata.txt` is `plugin_dependencies`. Those
are *inter-plugin dependencies*, i.e. one plugin requiring another plugin.

Looking at `plugins.xml` though I became a bit confused.
`plugin_dependencies` is missing. However, there is
`external_dependencies` (which is empty for every plugin as far as I can
tell). I traced it back on the server side and came across this:

https://github.com/qgis/QGIS-Django/blob/33b7786e5201f14e9a80f512da9e76f7b94ad772/qgis-app/plugins/views.py#L332
https://github.com/qgis/QGIS-Django/blob/4507e84a961ed6b877d6ccb5eec017d173b61b23/qgis-app/plugins/models.py#L466

On the server side, the field is called `external_deps` and labeled "PIP
install string" (while the string `plugin_dependencies` does not appear
a single time in the server-side code).

Just to be absolutely sure: `external_deps`/`external_dependencies` is
an unimplemented stub and has *nothing* to do with
`plugin_dependencies`, right?

If the above is true, inter-plugin dependencies can not be extracted
from `plugins.xml`. Actually resolving a full dependency tree on a
client then involves downloading the entire plugin, unpacking at least
its `metadata.txt` and then recursively repeating the process for all of
its dependencies. The current (client) implementation even appears to be
doing this in the actual plugin installation folder, right next to other
scary procedures. This puts unnecessary stress on servers and increases
the risk of broken installations on clients - considering that
inter-plugin dependencies are becoming more widely adopted. I'd like to
suggest to expose `plugin_dependencies` in `plugins.xml`. This would
allow the package manager on the client to tell the user *before any
harm is done* whether or not the tree can actually be resolved or not
(just like virtually all modern package managers do).

Best regards,
Sebastian