[GRASS-dev] [QGIS-Developer] Accessing GRASS GIS addons from within QGIS

[Nikos Alexandris]

* Nyall Dawson <nyall.dawson at gmail.com> [2019-02-07 17:05:14 +1000]:

>On Thu, 7 Feb 2019 at 01:41, Nikos Alexandris <nik at nikosalexandris.net> wrote:
>
>> 2) For the Processing Toolbox, my understanding is that it requires
>> significant effort to reflect the logic of a GRASS GIS module using
>> QGIS' Processing interface to GRASS GIS.  Am I wrong?
>>
>> If I go for the Processing option, however, is it possible to inegrate a
>> GRASS GIS add-on under the QGIS' Processing GRASS provider, at run-time?
>>
>> Essentially, is it possible to write (new) "description" files under
>> `python/plugins/processing/algs/grass7/description/` which are likely
>> placed under directories owned by the root/admin user?
>
>> If none of the above can ensure access to a GRASS GIS add-on through
>> QGIS, one that is to be installed using `g.extension` after having
>> installed QGIS and GRASS GIS, what would you then recommend?
>
>My recommendation:
>
>I would implement expose your GRASS add-on as its own processing
>provider. You would base this almost entirely off the existing
>processing grass provider, but with its own set of description files
>exposing only your add on modules. You should be able to do this by
>importing the existing grass provider classes, and overwriting the
>provider code to have a new ID/name/icon/etc.
>
>This would also make it easy to redistribute - you'd wrap your
>provider into a plugin, and then could distribute via the normal
>plugin channels. And if you do it right (and only import existing
>processing grass code, minimising the copy/paste of this code), then
>you're provider will automatically inherit any future fixes and
>features added to the main grass provider.

Dear Nyal,

thank you for your time and the recommendation.  I guess this is
currently the only reasonable approach to distribute the "provider" and the
plugin.

Kind regards, Nikos