[QGIS-Developer] Understanding plugin management in QGIS - exposing QgsPluginRegistry to Python?

[Sebastian M. Ernst]

Hi Matthias,

> Have a look at all the issues on db manager for example. Many of them
> are caused by duck-typing, interfaces not being implemented (properly)
> by subclasses, pieces that have been forgotten during refactoring ...

thanks for the directions, I will look into it.

> I would like it a lot to get a couple of pull requests that target such
> weaknesses.
> Such pull requests are normally accepted quite quickly and much
> appreciated.
> [...]
> No one is in the position to say no to this, the GPL grants you the
> rights for that :)

I'd issue pull requests if it was an easy repair. I was actually
starting to poke around because I thought I could add a feature. I ended
up thinking about a significant consolidation if not a rewrite (before
even considering adding features) because I think the code really needs
it. So before I begin to send pull requests your way, I decided to
explore what kind of changes you guys would be willing to accept
(short/long term) before I invest more time into it. If a re-write is
the lesser evil, this opens a bunch of interesting options /
opportunities, I'd say, and then it makes a lot of sense to ask for QGIS
developers' opinions.

> For your information: next to the plugin manager, there is also the
> Python console [...]

I have noticed ;) There are a few issues in the console that keep
annoying me, but my current focus is on the plugin system.

> This would be a very nice addition indeed.
> 
> Plans in this direction have been on our wish list for this year. We
> have just had some discussions with Olivier about this this week.
> 
> This topic would deserve it's own QEP and I'm very interested in knowing
> a bit more about what you are after here.

Well, the bottom line is more efficiently tapping into pypi and conda
packages. QGIS / OSGeo4W pretty much acts as a rather limited Python
distribution. It's missing a lot of interesting scientific packages that
currently see rapid development. Their distribution as part of QGIS /
OSGeo4W would probably go much beyond the scope and resources of the
QGIS project. If, on the other hand, QGIS was "simply" yet another
C++-heavy Python package within a larger ecosystem, let's say Anaconda,
this would add an interesting new perspective. I have been chasing the
idea that QGIS plugins (more specifically their meta data) are lacking a
lot of features of Python wheels or Conda packages. They really can not
carry dependencies (other than dependencies to other plugins, added in
QGIS 3.6 I believe). It's actually officially recommended to make Python
dependencies part of QGIS plugins' distribution files (c & p), which can
be a no-go for a number of good reasons. If you imagine that QGIS
plugins are instead (or additionally) distributed as conda packages
(with all of conda's package management features) while the entire thing
remains manageable through a simple GUI, the QGIS plugin manager, I can
see some interesting new use-cases and possibilities (especially for
non-technical and Windows users). This is more or less the gist of my
thinking.

>> If I want to develop my proof of concept (and actually proof that this
>> could work), I'd ideally need access to at least some methods from
>> `QgsPluginRegistry`. Back to my original question: Can this class be
>> accessed from Python? Or could someone help me with exMy suggestion
>> would posing the
>> relevant methods (from one/the relevant instance of this class) to
>> Python? I have no trouble with building QGIS from source if required
> 
> No. It is in app, and the app library is not exposed to Python.

How complicated is it to change that, let's say for just
`QgsPluginRegistry`, with a really ugly patch perhaps (that is not meant
to go into master)?

Best regards,
Sebastian