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

[Rashad Kanavath]

On Thu, Feb 8, 2018 at 11:32 AM, Victor Olaya <volayaf at gmail.com> wrote:

>
>
>>
>> OTB's proposed solution was that plugin or provider algorithm if
>> activated can find otb installation. If not found, there is code which will
>> download and install otb packages and configure it for users.
>>
>
> I still don't see why this cannot be done if OTB provider is a separate
> plugin. Users can install a plugin with the provider, and then that
> provider can have the logic to automatically download OTB, install it, or
> do whatever is needed in case OTB is not found already installed.
>
> I think is is good to educate our users a little bit. We are talking about
> people that will be using complex algorithms for performing advanced
> analysis. I guess we can expect that they can install a plugin themselves
> and it is not a traumatic experience for them... Looks like installing a
> separate plugin it's some sort of cruel chinese torture...when it takes
> just 3 mouse clicks.
>
> I agree with Giovanni, there is no need to provide something that has
> everything installed out-of the box. Also, take into account that reading
> the files that contain the algorithm descriptions takes time (plus, there
> might be some additional checks performed when populating the toolbox).
> People not doing analysis should not have to suffer that extra loading
> time...
>

QGIS increases no of algorithms for a provider. It is simple as that. OTB
has less than 80 applications and coming to QGIS, it will be 100 or 150.
(no interest to count them in qgis)
 And OTB was reading descriptor from xml which is going to be now csv like
others.
Given all that info, I won't be surprised if it takes more time in future
because of new algorithms added to providers. If QGIS was reading proper
way or even open to accepting fixes.

The entire proposal/request to put back OTB was that decision was made on
OLD code. when the update code is there, it has less problems.
Based on concerns raised by other developers no matter if you can fix it,
they can't be put back. This single point was fueling this and other
threads.
Also discussion wasn't started with "why no providers are included?". It
was why some of them are removed even if there is an offer to help!

I don't care enough to continue this discussion about plugin or not plugin.

But aside all decision making stuff, can you check what is to be done in
this PR?
https://github.com/qgis/QGIS/pull/6272
It is something worthy a discussion and not a plugin or not. I was asking
because QGIS 3 is near and diff is not that big.
If there is something extra need to be done to get this merged, I would
happy to hear about it.


> About the R plugin not being available now...well, it's in a separate repo
> and can be adapted to QGIS 3, packaged and published. No one has taken care
> of that, it's true, but that only means we have no R support. If the R
> provider was be in core, it would mean that we would have a dead or
> malfunctioning provider being shipped with QGIS. That is a much worse
> option. And I dont see why, if someone is willing to fix that R provider,
> having it in core will make it easier.
>
> Cheers!
>



-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20180208/52fc8dd6/attachment.html>