Policy and standards for plugins in QGIS 3.0

[timlinux]

QGIS Enhancement: Policy and standards for plugins in QGIS 3.0

STATUS: DRAFT

Date 2017/04/02

Author Tim Sutton (@timlinux)

Contact tim@qgis.org

maintainer @timlinux

Version QGIS 3.x

Summary

In QGIS 3.0 we will 'clean house' and provide our users with a cleaner, more cohesive QGIS. This proposal ponders the future of plugins within QGIS 3.0.

Some proposed guidelines:

• Each plugin should be under maintainership of a developer: We would like to know that plugins that make there way into the mainstream QGIS code base are not 'dumped' there by someone looking to offload the responsibility of maintaining that plugin, but rather are added to core because it represents valuable functionality that we think should be part of QGIS 'out of the box' and that someone has undertaken to maintain over the long term.
• Each plugin should adhere strictly to QGIS HIG etc. The HIG (Human Interface Guideline) for QGIS is intended to ensure a consistent experience for users within all parts of the application. Currently the HIG needs a lot more work in order to be comprehensive, but nominally, any plugin (or other code) introduced to QGIS should strive to provide the same user interface paradigm as the rest of QGIS.
• Core plugins should have broad application to all users: If a plugin is to make it's way into the core QGIS code base, it should not be 'niche' in its application.
• As part of the incorporation into core, we should consider mandating that plugins be implemented directly in QGIS (not as plugins). In general if a plugin has reached the point of wide adoption or utility and is being considered to go into core, we should consider mandating that the contributor should submit his work, not as a plugin, but as a properly integrated plugin for QGIS.
• Python plugins which become popular features and are in core should be considered as candidates for being ported to C++: This kind of activity can be a good candidate for our grant scheme. As part of this process, we may request that the author migrate their plugin from Python to C++, or at least provide a robust rationale of why the plugin should be maintained as python code. Legitimate reasons for maintaining the plugin as python code could include:
  • dependencies on third party libraries
  • the size and scope of the plugin make porting unfeasible
  • lack of C++ knowledge in the maintainer of the Python plugin, and no C++ able/prepared to take ownership
  • any others? The rationale for porting to C++ is further expanded on below:
• Performance-critical features should be implemented in C++: Although it is possible to write performant code in python (and non-performant code in C++), it should be generally assumed that we will obtain better performance, especially for intensive processing, in C++.
• Functions with high reuse potential should be implemented in C++: We would like to establish a library of re-usable code and algorithms so that the functionality added to QGIS gradually expands in depth and breadth. When code is added in python, it precludes using that code as the building blocks for higher order functionality in the QGIS C++ API. Also some platforms (e.g. QField) do not provide a python environment, so a decency of Python code reduces the potential audience for that code.

Cleaning house

Here follows a proposed list of eEssential plugins (Python):

• Resource sharing*
• Processing
• MetaSearch
• DB Manager
• Linear referencing

And proposed essential plugins (c++) - should become core functionality:

• Geometry checker
• Georeferencing tool
• Coordinate capture - include in identify tool?

Possible candidates for removal C++ plugins

• Globe?

*For the resource sharing plugins we should:

• Establish if Akbar will maintain it
• See if others are happy to include it in core

Moving forward

My proposal for progressing this QEP is this:

• Add a section in the new developers guide that is being worked on to include the guidelines above (after edits and community review).
• Hold a voting member vote to determine which plugins should remain in core, which should be removed and which should be migrated from plugins into core functionality.
• Plugins that are in core should be rather implemented like the plugin manager is - enabled and ready to use and no longer user dis/enabled plugins.
• Establish a list of maintainers for each plugin (in plugin or merged form) and update the project maintainers list accordingly.

Backwards Compatibility

None

Issue Tracking ID(s)

None

Votes

None

[nyalldawson]

@timlinux is this about included plugins or all plugins (including repo ones)?

[timlinux]

Hi @nyalldawson - sorry I was saving as I went along - perhaps reload the page to see a more complete transcript.

[timlinux]

@timlinux is this about included plugins or all plugins (including repo ones)?

@nyalldawson I would say generally it applies mainly to those plugins shipped with QGIS - but we would also like to clarify the process of when and how a plugin can move out of a plugin repo and in to core.

[alexbruy]

@timlinux which Routing pluign do you mean? If you are talking about RoadGraph, it is already removed.

Also personaly I think that CSW support should be not a plugin, but a core feature like other OGC services. This even more important with ongoing work on metadata support in QGIS.

[elpaso]

Each plugin should be under maintainership of a developer

Totally agreed, this seems so obvious to me that I'd not even though of writing it down, but if you want to, I wonder why the plugins should be treated differently from the rest of the code.

I mean, that if a developer develops and commits a cool new feature in core, shouldn't this be taken as an implicit commitment to maintain it? At least for a reasonable amount of time.

I don't see the need to make a distinction for the plugins, even if they are probably easier to isolate from the rest of the core contributions, that tend to spread over different areas of the code.

[tomchadwin]

Python plugins which become popular features and are in core should be considered as candidates for being ported to C++ […] Legitimate reasons for maintaining the plugin as python code could include: […]

• any others?

• lack of C++ knowledge in the maintainer of the Python plugin, and no C++ able/prepared to take ownership

[timlinux]

@elpaso wrote:

Totally agreed, this seems so obvious to me that I'd not even though of writing it down, but if you want to, I wonder why the plugins should be treated differently from the rest of the code.

I mean, that if a developer develops and commits a cool new feature in core, shouldn't this be taken as an implicit commitment to maintain it? At least for a reasonable amount of time.

I don't see the need to make a distinction for the plugins, even if they are probably easier to isolate from the rest of the core contributions, that tend to spread over different areas of the code.

Yes you are right this should be an implicit requirement for any new code contributed to QGIS. I think it is always worthwhile to reinforce the message though.

[borysiasty]

@timlinux you mentioned the Plugin Manager. For a few years it's in core, not a plugin. Actually, do we really need to keep the 'core plugins' as plugins? I guess it's confusing for users some plugins are not deinstalable. I'd rather see them fully merged with the code base, like it's now with the PuginManager (c++ classes) and PyPluginInstaller (Python package). The main advantage of keeping them as plugins is the possibility to disable unwanted or crashing ones. But is it really so important? It's just my 2 cents, I believe you investigated it deeper during the meeting.

[timlinux]

@timlinux you mentioned the Plugin Manager. For a few years it's in core, not a plugin.

@borysiasty ooops - I was aware of that :-P

Actually, do we really need to keep the 'core plugins' as plugins? I guess it's confusing for users some plugins are not deinstalable. I'd rather see them fully merged with the code base, like it's now with the PuginManager (c++ classes) and PyPluginInstaller (Python package).

Yeah this is one of the points I was trying to make - if we ship something as part of core, it should not be a 'plugin' but just 'enabled and working' as per any other feature of QGIS core.

[timlinux]

@borysiasty following from your comments above, I added a section to the proposed way forward:

• Plugins that are in core should be rather implemented like the plugin manager is - enabled and ready to use and no longer user dis/enabled plugins.

[timlinux]

@tomchadwin wrote:

lack of C++ knowledge in the maintainer of the Python plugin, and no C++ able/prepared to take ownership

Yes good example, Ill add it to the QEP thanks.

[timlinux]

@alexbruy wrote:

@timlinux which Routing pluign do you mean? If you are talking about RoadGraph, it is already removed.

Thanks I removed it from the list.

Also personaly I think that CSW support should be not a plugin, but a core feature like other OGC services. This even more important with ongoing work on metadata support in QGIS.

I agree 100%! Thanks for your comments.

[borysiasty]

@timlinux - great. The list is getting shorter :)

Btw. the split between c++ PluginManager and Python's PyPluginInstaller may be a good* example of porting most code to c++ and only leaving python-related stuff in Python (your fifth point).

*) maybe not good, but at least just an example ;)

[manisandro]

This might be a good moment to send an update concerning globe: I've upstreamed patches to osgQt (https://github.com/openscenegraph/osgQt/pull/3) and osgEarth (https://github.com/gwaldron/osgearth/pull/890) to allow distributions to ship side-by-side installable packages for osgQt4/osgQt5 and osgEarthQt4/osgEarthQt5. This is a precondition for distros to even be able to ship osgEarthQt5, since there are still some osgQt4 users out there. I also did some initial work to get the globe compiling again (https://github.com/manisandro/QGIS/commit/3ad287b7c38e7c07ffd427b12d2952a29e28ffdb). Unfortunately the big blocker at the moment is that osgEarth simply seems to be broken when used with Mesa drivers (at least, Intel, which I tested against). I posted upstream [1] but got no reaction so far. I would not like to write off the globe plugin and still plan to invest some time to get it to work, but it won't happen immediately (though clearly I know the freeze is approaching).

And while I'm at it, I'm currently doing some heavy work on the geometry checker at the moment to support for checking multiple layers at once resp. for the topology checks to work on multiple layers.

[1] http://forum.osgearth.org/osgEarth-2-8-on-mesa-intel-td7590671.html