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 _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
