[Qgis-developer] Proposal: Having all Processing providers as independent components

[Médéric Ribreux]

Le 2016-12-06 07:39, Paolo Cavallini a écrit :
> Hi Victor,
> 
> Il 06/12/2016 07:33, Victor Olaya ha scritto:
>> Let me know what you think
> 
> I like the idea of modularity. However, requiring the user to do extra
> steps to use GRASS, SAGA, GDAL/OGR, that are already shipped with our
> packages, seems a bit of hindrance.
> All the best.

Hello,

I do agree with	Paolo point of view. Users need	to have	a ready	to use
Processing configuration for most of the 'external' providers. As the
main installation package (for MS-Windows) incorporates GRASS, end
users expect that they can launch GRASS	algorithms directly into QGIS
(via Processing of course).

On the software development side, I advocate to	keep the external
providers into core for the moment. I have worked on the GRASS7
provider and being a part of core is something that is very convenient
and comfortable	for me because most of the time, I need	to add some
(often minor) evolutions into Processing core before being able	to add
features/fix bugs into GRASS7 provider.	Furthermore, I can benefit
from QGIS infrastructure, particularly for bug tracking.

I fear that it could be	much less easy to maintain an independent
plugin provider	because	it involves more sysadmin work for the
maintainer (need to open a dedicated code repository, a dedicated
bugtracker). I know that this part seems to be quite easy with Github
but it could also add more work	for things to be done.

On my last commit, I have made some minor modifications	for three
external providers in only one PR. Having independent plugin providers
would have implied 3 PRs.

I am not completely closed to focus the	dev work into Processing core
but I think that external providers are	not ready to be	externalized
(at least for GRASS7):
- we should wait for 3.0 to be released	because	we need	to finish the
port to Python3/Qt5 port, otherwise, there is a	real risk for
discarding some	external providers for lack of 3.0 support.
- we should also try to fix all bugs (at least the major ones) before
thinking to externalize	something. This	is not the case	for GRASS7
(but I am working on it).
- external providers need (nearly) complete unit test coverage.
- we need sufficient time to get feedback from	users, after the 3.0
release, to get assured that there is no major problem involved in the
Python3/Qt5 port.

As a conclusion, I am not completely close-minded to external
Processing providers externalization but I think that it should	be
postponed after 3.0 or 3.2 release...

Cheers
-- 
Médéric RIBREUX
https://medspx.fr