[QGIS-Developer] Keeping OTB algorithm in qgis processing

[Nyall Dawson]

On 1 February 2018 at 20:01, Rashad Kanavath <mohammedrashadkm at gmail.com> wrote:
> Hello,
>
> Processing plugin allows to integrate other toolboxes. IIUC, this was one of
> the features of it.
> So when you say integration of so and so toolboxes are total mess, you might
> think back.

I think there's a misunderstanding/language barrier at play here -
no-one meant that the code is a mess, just that the end result of the
QGIS team trying to maintain 3rd party providers resulted in an
inferior experience all round - for users, qgis developers AND the
underlying library developers (whom I'm sure don't appreciate being
blamed when a QGIS processing algorithm is mis-using their API).

Yes, one of Processing's big strengths is its ability to integrate
other toolboxes and make 3rd party libraries accessible within the
QGIS environment and tie them together into models. Another one of
QGIS' great strengths is its strong plugin ecosystem, which allows
anyone the ability to create plugins and extend QGIS, and not be tied
into the core QGIS development practices and release schedules. That's
why plugin-based providers are the BEST solution in my opinion.

> Nobody had seen new changes to otb algs so all of your comments are on old
> version.  Why so rush?
> Okay, it easy to reject stating the same reason over and over again. I
> understand that.

Just to be clear - no-one is commenting on your code quality or
targeting OTB specifically. It's the question of whether or not
Processing providers which depend on other libraries should be
included in the main install or moved to plugins which we are
debating. So please, don't take any of this as criticism of your code
or (much appreciated) efforts.

> What happens at end, a processing plugin with zero providers?

Far from it. My vision would be:

- core install: only includes the native QGIS providers (c++, Python
and 3D) and the GDAL/OGR provider (since it's impossible to build QGIS
without GDAL we can be 100% sure that it's always available wherever
QGIS is installed). Maybe GRASS provider too, since GRASS is very
heavily linked into QGIS due to the GRASS provider and c++ GRASS
plugin.
- via QGIS' plugin ecosystem: a whole world of providers ready to
install for users, including SAGA, OTB, lastools, R, PySAL, etc...

> Now the reason OTB had to maintain list of "supported" version is due the
> fact that processing plugin does not allow to group parameters.
> So the issue of a provider being total mess not fully related to provider
> itself. If 90% of provider algorithm which you use, cannot be even
> integrated into processing where will be the actual problem. I see a lot of
> good changes in qgis processing and providers can greatly benefit from it
> now.

Can you elaborate on this please? I'm not aware what the "group
parameters" issue is.

> All those people blindly rejecting this proposal should have waited for new
> changes.
> I mean, I just put a proposal to lower the burden as much as possible. And
> all those issues raised by Alex, Nyall and others will be considered in the
> new diff.
> Once I prepare changes, you can reject it!. You are voting -1ss on old
> plugin code something I consider a mess to work with for both teams.

Why? In the past we've always found that discussing plans upfront
benefits everyone and prevents development effort in an approach which
won't be accepted upstream.

In summary, can you please outline the reasons why you think
publishing this as a plugin is not ideal?

Nyall