[QGIS-Developer] [GRASS-dev] External providers in QGIS

[Nyall Dawson]

On 9 February 2018 at 00:20, Moritz Lennert
<mlennert at club.worldonline.be> wrote:
> On 08/02/18 15:08, Nikos Alexandris wrote:
>>
>> I guess, there are numerous cases like this one. What would,
>> effectively, mean a removal of external providers (in this case GRASS
>> GIS)?
>
>
> Let's make it clear once and for all: noone is speaking about the complete
> removal of external providers. The issue is where, how and by whom they
> should be maintained, i.e. within the QGIS core code base, or as plugins.
>

Yes, this is a great point. I think this discussion has got
sidetracked with some misunderstandings.

Here's the situation as I see it:

------------
The past
-----------

We (the QGIS project) have struggled to keep a bunch of providers
stable and available with the base QGIS install, and the current
maintainers (Alex and Victor, others) have (understandably) struggled
with the burden of maintaining these alone and the time commitment
required to do so. Users have been frustrated by breakage which occurs
when the algorithms they depend on break due to changes in underlying
libraries for which the processing providers have not been adapted.

Despite this, I'd say overall it's worked OK-ish up to now, but
definitely with lots of room for improvement.

-------------
The goals
-------------

I think everyone involved is in agreement that processing's strength
comes when there's many providers available and it's able to tie
together processes regardless of which provider or library they come
from. So I'd say our common goals are:

1. Encourage development of as many processing providers as possible
2. Make it easy for developers to create and maintain these providers
3. Make it easy for users to be able to use the providers
4. Make everything stable and painfree for users

Any disagreements? No? Good ;)

So if we agree that those are the end goals, we should be using them
to drive this discussion.

-------------------
The questions
-------------------

The open, debatable questions are:

- Which is the best approach for allowing easy maintenance of
providers (*regardless* of whether the provider is maintained by the
core QGIS team or a 3rd party)? Is it keeping the code in the master
codebase and locking to QGIS releases, or publishing via plugins and
having independent release schedules? Which approach will encourage
more active maintenance of these providers and share the burden of
this maintenance?

- Who should be responsible for maintaining the providers? Should
maintenance be done by the QGIS core developer team or by 3rd parties?

- How do we make these tools available for ALL interested users? How
can we ensure that 3rd party dependencies are always available and
have a consistent feature set, regardless of which platform the user
is running? Does having the QGIS team or 3rd parties maintain the
provider help make the tools more readily available? Does having the
providers in master or plugins make the 3rd party dependencies more
readily available or not?

- How can we ensure that providers are well tested and don't break
with changes in QGIS OR from 3rd party library updates? Does having
the QGIS team or 3rd parties affect this stability? Does having the
providers in master or plugins affect this stability?

- Is it a core requirement that 3rd party providers are installed with
EVERY QGIS install, or is it acceptable to require interested users to
manually install the tools which they find useful? If the second
option is preferred, then how can we ensure that users are aware of
the availability of these tools?

- Does it make it easier for everyone involved if we just delete all
the python bindings for processing and only allow core, native, c++
algorithms, and merge all our codebases into a single unified
QGIS+SAGA+GRASS+OTB+R mega package? (I joke... ;)

This isn't an easy discussion, but please, let's keep the discussion
civil, factual, and informed, and driven by the above goals.

Nyall