[QGIS-Developer] Can't find SAGA devel versions after r413c6e5

Rainer Hurling rhurlin at gwdg.de
Thu Jun 8 06:47:33 PDT 2017


Hi Pedro,

Thanks also for your explanations.

Am 08.06.2017 um 15:14 schrieb Pedro Venâncio:
> Hi Rainer,
> 
> That is not the case. The problem is that SAGA team changes very often 
> the sintax of the SAGA modules, even between minor updates, wich causes 
> problems with SAGA Processing implementation.
> 
> A big issue is the creation of models and scripts in Processing, using 
> SAGA algorithms. With that frequent changes, they become obsolete. For 
> instance, I've created a set of modules with dozens of operations, that 
> become unusable twice because of SAGA sintaxe changes. This prevents 
> much people to create Processing models and scripts, and share them.
> 
> The solution discussed and adopted was to support only a LTR version of 
> SAGA, and make it the default for QGIS 2.18.9+ and QGIS 3.x, so that any 
> user on any operation system have the same SAGA version, wich ensures 
> that any model created or shared is fully operational.
> 
> By other hand, is what Alexander said, there is no workforce to ensures 
> the check and update of descritpion files, every time SAGA releases some 
> minor or major version.
> 
> Hope this make sense to you.

Until here, I am with you and as I wrote in my initial mail, I am aware 
of the problems with changing API etc.

My point is, that there are systems without an LTR version of SAGA GIS 
and without an easy possibility for normal users to additionally install 
the LTR version. The users only have a QGIS installation without any 
SAGA GIS processing.

For systems like this (i.e. FreeBSD) it would be nice, if QGIS would 
recognize the presence of a more recent, installed version of SAGA GIS. 
In this case, QGIS could explicitely warn the user about possible API 
breakage and that he/she should expect not every SAGA module to work 
correctly.

> The suggestion of Alexander, If I understood correctly, is that the 
> group of users from FreeBSD can always fork the Processig SAGA, and 
> support newer versions as a new Processing Plugin.

Yes, this could be possible in theory. But most likely, no one with 
adequate knowledge will be found. ATM, it seems to me, that the most 
realistic option for FreeBSD is to add some extra patches into the port, 
which would allow us to use newer SAGA GIS version in a restricted way. 
Many, many of the SAGA GIS tools will work even with newer versions. 
Better than nothing ;)

So, based on some small patches, showed in my previous mail, I will 
allow this behaviour for the FreeBSD port of QGIS.

Thanks again for your explanations.

Greetings from Göttingen in Germany,
Rainer Hurling


> Best regards,
> Pedro Venâncio
> 
> 
> 
> 2017-06-08 11:45 GMT+01:00 Rainer Hurling <rhurlin at gwdg.de 
> <mailto:rhurlin at gwdg.de>>:
> 
>     I forgot to mention, that if only FreeBSD users should have the
>     problem with newer SAGA GIS versions and not having an LTR version,
>     a local patch in the FreeBSD port is also conceivable.
> 
>     Something like the following patches makes the processing tools for
>     SAGA GIS, newer than version 2.3.x, 'functional' again on FreeBSD:
> 
> 
>     --- python/plugins/processing/algs/saga/SagaUtils.py.orig     
>       2017-06-06 19:35:06.000000000 +0200
>     +++ python/plugins/processing/algs/saga/SagaUtils.py    2017-06-08
>     10:49:02.387866000 +0200
>     @@ -26,6 +26,7 @@
>       __revision__ = '$Format:%H$'
> 
>       import os
>     +import platform
>       import stat
>       import subprocess
>       import time
>     @@ -57,7 +58,7 @@
> 
>       def findSagaFolder():
>           folder = None
>     -    if isMac():
>     +    if isMac() or platform.system() == 'FreeBSD':
>               testfolder = os.path.join(QgsApplication.prefixPath(), 'bin')
>               if os.path.exists(os.path.join(testfolder, 'saga_cmd')):
>                   folder = testfolder
>     @@ -82,7 +83,7 @@
> 
> 
>       def sagaPath():
>     -    if not isWindows() and not isMac():
>     +    if not isWindows() and not isMac() and not platform.system() ==
>     'FreeBSD':
>               return ''
> 
>           folder = findSagaFolder()
>     @@ -101,7 +102,7 @@
>               fout.write('set SAGA_MLB=' + sagaPath() + os.sep +
>                          'modules' + '\n')
>               fout.write('PATH=%PATH%;%SAGA%;%SAGA_MLB%\n')
>     -    elif isMac():
>     +    elif isMac()  or platform.system() == 'FreeBSD':
>               fout.write('export SAGA_MLB=' + sagaPath() +
>                          '/../lib/saga\n')
>               fout.write('export PATH=' + sagaPath() + ':$PATH\n')
>     @@ -130,7 +131,7 @@
> 
>           if isWindows():
>               commands = [os.path.join(sagaPath(), "saga_cmd.exe"), "-v"]
>     -    elif isMac():
>     +    elif isMac() or platform.system() == 'FreeBSD':
>               commands = [os.path.join(sagaPath(), "saga_cmd -v")]
>           else:
>               # for Linux use just one string instead of separated
>     parameters as the list
>     @@ -146,7 +147,7 @@
>                   stderr=subprocess.STDOUT,
>                   universal_newlines=True,
>               ).stdout
>     -        if isMac():  # This trick avoids having an uninterrupted
>     system call exception if SAGA is not installed
>     +        if isMac() or platform.system() == 'FreeBSD':  # This trick
>     avoids having an uninterrupted system call exception if SAGA is not
>     installed
>                   time.sleep(1)
>               try:
>                   lines = proc.readlines()
> 
> 
>     ---
>     python/plugins/processing/algs/saga/SagaAlgorithmProvider.py.orig
>     2017-06-08 02:16:08.000000000 +0200
>     +++ python/plugins/processing/algs/saga/SagaAlgorithmProvider.py
>     2017-06-08 11:15:09.732518000 +0200
>     @@ -73,7 +73,7 @@
>     self.tr <http://self.tr>('Problem with SAGA installation: SAGA was
>     not found or is not correctly installed'))
>                   return
> 
>     -        if not version.startswith('2.3.'):
>     +        if version < '2.3.':
>                   ProcessingLog.addToLog(ProcessingLog.LOG_ERROR,
>     self.tr <http://self.tr>('Problem with SAGA installation:
>     unsupported SAGA version found.'))
>                   return
> 
> 
> 
>     Am 08.06.2017 um 11:42 schrieb Rainer Hurling:
> 
>         Hi Alex,
> 
>         Thanks for the quick and detailed answer.
> 
>         Am 08.06.2017 um 11:29 schrieb Alexander Bruy:
> 
>             Hi Rainer,
> 
>             2017-06-08 10:24 GMT+03:00 Rainer Hurling <rhurlin at gwdg.de
>             <mailto:rhurlin at gwdg.de>>:
> 
>                 For some reasons, we don't package our system with
>                 different versions of
>                 SAGA GIS. Recent FreeBSD comes with SAGA GIS version
>                 3.0.0, I am working on
>                 an update to version 4.1.0.
> 
>                 With your latest updates to QGIS (r413c6e5), newer
>                 versions of SAGA GIS than
>                 2.3.x are not recognized any more :(
> 
>                 I am familiar with the background, that QGIS processing
>                 only garantees to
>                 work well with the SAGA GIS LTR version. But there was a
>                 kind of tacit
>                 agreement for several years now, that QGIS processing
>                 tools also accepted to
>                 display (and somewhat work with) newer SAGA GIS versions.
> 
> 
>             Previously QGIS Processing supported multiple SAGA versions,
>             but as SAGA
>             devs often changed API even between minor versions it was a
>             real pain to
>             maintain compatibility and provide users with robust and
>             working SAGA inteface.
>             Because for each change in SAGA API we need not only update
>             algorithms
>             descriptions but also add some workaronds in the Processing
>             source code.
> 
>             After release of SAGA LTR we had several long discussions
>             and finally decided
>             that better to have good support for single SAGA version
>             that multiple partially
>             broken version. That's why support for all other versions
>             was removed. We also
>             removed option to choose another SAGA installation, as this
>             makes no sense
>             now and can lead to confusion in case when user select
>             unsupported SAGA
>             version.
> 
> 
>         In principle I understand this point of view, but it makes it
>         relatively difficult to identify the necessary changes for newer
>         SAGA GIS versions.
> 
>         And as I outlined before, there are constraints on some OS for
>         the presence of newer SAGA GIS versions. In the past, the QGIS
>         user was able to use most of the SAGA GIS functions, as only
>         some of the functions had bigger API changes.
> 
>                 Now my request: It would be fine and at least important
>                 for FreeBSD users,
>                 to have the possibility to use SAGA GIS > 2.3.x with
>                 QGIS 2.18.9 again.
> 
> 
>             I'm afrad this is not possible, as we have no resources to
>             keep algorithms
>             descriptions and, more importantly, source code updated with
>             numerous SAGA
>             API breaks in every SAGA release.
> 
>             As an option I can suggest to create altenate SAGA provider
>             plugin which will
>             support non-LTR SAGA versions.
> 
> 
> 
>         This would be a very nice option to have such an additional
>         support. A provider plugin for (newer) non-LTR SAGA versions
>         could throw a warnings, that this SAGA GIS version is not fully
>         supported and the user has to expect problems ...
> 


More information about the QGIS-Developer mailing list