[QGIS-Developer] QGIS 3 > Processing: some test

[Nyall Dawson]

On 10 June 2017 at 06:46, Giovanni Manghi <giovanni.manghi at gmail.com> wrote:
>> * Aspect throws an error:
>
>
> is this GDAL's aspect?

No - native QGIS one. None of the GDAL/OGR provider is ported to the
new API yet and is not available in nightly builds.

> is expected that -for example- all the tools, even not QGIS native
> ones to be somehow fixed in processing/QGIS3 because of the overhaul
> that is going on?

Native, GDAL, grass and saga will be ported. It's low on my priority
list right now though, so if anyone wants to step forward and port
these now then it'd be much appreciated. My priorities are:

1. bringing back complete functionality in the run alg dialog
2. batch mode
3. scripts
4. modeler
5. resurrecting remaining algs
6. adding new stuff to existing algs (dynamic parameters, porting to c++, etc)

>  If yes this is also true for Processing plugins that
> make uses of external programs like ogr2ogr, circuitscape and many
> other examples?

No - processing  plugin maintainers are responsible for porting their
own code to 3.0, just like all other plugin maintainers.


We probably need to bring up a discussion sometime about how to handle
user's migrations to processing 3.0. As I see the situation:

- we have had some algs which were available in 2.x removed. This
breaks existing models which used those algorithms.
- we have a bunch of "duplicate" native algs, some of which have been
"deprecated" in 3.0. Deprecation just hides them from the toolbox - it
doesn't break existing models. This is a HUGE amount of baggage to
carry around and maintain, for little benefit.
- user scripts will be broken, because they use the old API
- the remaining algs still need a lot of cleanup. We have a lot of
duplicate functionality spread across the QGIS algs, which would be
good to address for 3.0

I'd like to raise the possibility that we break compatibility with 2.x
models in 3.0, and require that users re-create their models using the
new set of available algorithms. I personally think this is acceptable
to do, given that:

- 3.0 is a major release. Some changes to user workflows and existing
projects are expected. Better to make the break now then in 3.2/other
future 3.x releases.
- It can be installed side-by-side with 2.x, allowing users to open
existing models in 2.x and step by step recreate their models in 3.0
world.
- Any scripts inside models will be broken and need to be updated
anyway (due to new PyQGIS API in 3.0 + python3 + Qt5 - there's no way
to automatically port these)

Nyall