[gdal-dev] [Qgis-developer] Processing algs & plugins... should we actively pull into master?

[Ari Jolma]

Interesting. Let me bring my relative outsider's and newcomer's view 
into this. Although a long time QGIS user, I've never really dug into 
the Processing tools.

I'm working on a project, where one part is a plugin - mostly a 
relatively simple set of dialogs that integrate with other parts of the 
QGIS GUI. In another part of the project I develop datasets - and I've 
written some processing tools for that based on GDAL. I just yesterday 
cleaned two of them up a bit and put them into github and mentioned that 
on gdal-dev (I cc this email to gdal-dev). They're Perl programs that 
use also other Perl modules.

My intent is to release the plugin to my end users through a website - 
the QGIS plugin system allows one to add new library URLs, so I just 
need to write an XML file and put the plugin into a zip and upload that 
to our server to release a new version. I can make that into "make dist" 
or something. I'd like to keep this separate from the official plugin 
repository for separate identity and maybe because the plugin is really 
for this specific purpose without wider interest at least for now.

I just studied the Processing tools because it seems that maybe I could 
also make my processing tools available for my end users (or at least as 
a formal deliverable of our project) that way. There seems to be two 
possible approaches: 1) get the tools into QGIS-Processing or 2) make a 
distribution and ask the end users to install them and use the "Add 
script from file" tool in Processing tools (won't work out of box 
because python extension is hard coded there). The tools I've made are 
pretty generic but I wrote them as pure CLI tools and the other one I 
use for huge rasters so it takes a lot of time why I put them running 
into some cloud computers. Anyway I definitely see a benefit in running 
them from within QGIS and distributing them to end users - and with an 
additional code layer the input and output could be tied to layers in 
QGIS and dialog boxes. The same way as GDAL utilities are now usable 
from QGIS.

The QGIS Processing tools is already now a huge collection of tools. 
Some tools are there and directly usable (GDAL for example since I have 
GDAL in my computer), some tools can be downloaded for use, and some 
tools require that I install more software into my computer (TauDEM for 
example).

I see dangers in that one can easily download code from the web into 
his/her computer and execute it easily. This will be an issue at least 
with IT support of my end users.

I see the benefit of peer control/help/review over add-ons I develop and 
make usable by others in QGIS.

Right now I'm a bit confused and also perhaps awed by the potential of 
the QGIS Processing tools.

Cheers,

Ari


08.02.2017, 18:49, Alex M kirjoitti:
> On 02/06/2017 01:24 AM, Paolo Cavallini wrote:
>> Il 06/02/2017 10:21, Victor Olaya ha scritto:
>>
>>> Just let make sure that we have some clear acceptance criteria (algs
>>> with tests, trying to follow some "best practices" and using
>>> Processing methods when possible, etc).
>> right, what could be the procedure then? whan I see a submitted pluygin
>> that qualifies for this should I warn you (and Nyall) for analysis
>> before suggesting it to the dev?
>> All the best.
>>
> I thought that https://github.com/qgis/QGIS-Processing was intended for
> these kinds of algorithms. It's centralized, but not core, intended for
> pure methods instead of plugins.
>
> Perhaps the confusion is that the Plugins and the Processing add-ons
> have 2 different installers, and it's not obvious that both exist?
>
> This seems like the start down the path, where after addition of tests
> and code review it might then go to core.
>
> Thanks,
> Alex
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer