Open nyalldawson opened 3 years ago
Huge +1 from me.
I understand the problem yet the author, I believe, publishes the saga next gen plugin?! (Definitely not an accusation here as I understand his full commitment to the QGIS project.).
My question is what is the advantage of removing the official QGIS support over favouring the plugin approach? Seems it would move the burden from a team of developers to individual plugin programmer who can more easily choose to drop a project.
I believe the root of the problem is the coordination between the SAGA developers and the QGIS team??? Has a recent attempt been made to bridge this problem?
I just find that this is the beginning of the end for the SAGA GIS integration and that would be a shame as SAGA does bring much needed algorithms to QGIS. Just my grain of salt.
Cheers
I understand the problem yet the author, I believe, publishes the saga next gen plugin?! (Definitely not an accusation here as I understand his full commitment to the QGIS project.).
That's correct -- but see below
My question is what is the advantage of removing the official QGIS support over favouring the plugin approach? Seems it would move the burden from a team of developers to individual plugin programmer who can more easily choose to drop a project.
The thinking here is actually the opposite. There's a huge barrier of entry for people contributing to the main QGIS code repository which plugins just don't have. Moving this functionality across to a 3rd party plugin was actually intended as a way to grow the contributor base for the plugin and generate more interest in a bigger team maintaining it. (While I do publish one of the plugins, I have no personal interest in maintaining it myself. I publish the plugin purely as a means to facilitate OTHERS in contributing to it).
Unfortunately to date the SAGA Nextgen plugin hasn't side much contributions. I'd attribute that to the bulk of QGIS users only running the built-in SAGA provider and having no idea that there's even better alternatives out there. If we advertise that the QGIS one is unmaintained, I'm hoping it will drive motivated users who want to see SAGA well supported to actively support the 3rd party plugins.
(Another benefit of plugin based provider is that updates can be pushed at any time, independent from the QGIS release schedule. There's also the option of multiple plugins covering different SAGA versions, which isn't something which is ever going to happen with the inbuilt provider).
I believe the root of the problem is the coordination between the SAGA developers and the QGIS team??? Has a recent attempt been made to bridge this problem?
Yes -- and SAGA team has helped by adding support for automatically generating the description files. But the SAGA/QGIS teams can't address the underlying issue causing conflict, which is the hard dependency between QGIS and SAGA versions. So unless the SAGA team stopped all changes and stuck with a stable API guarantee for all future releases were still going to be running into issues. (That's not something they have to do just for QGIS sake, and they are totally reasonable in deciding NOT to do this. QGIS just needs to adapt to upstream SAGA's plans for their project, and my proposal is the way I think QGIS should do this).
Thanks for the information.
Change the version detection warning to a generic "SAGA is not officially supported by QGIS" warning, and show regardless of installed SAGA version.
I suggest that instead of only advertising that SAGA is not officially supported by QGIS, users also be warned that there are third party alternatives, possibly naming them.
This is almost a duplicate of https://github.com/qgis/QGIS-Enhancement-Proposals/issues/226. As per my QEP, I agree with this completely. This also helps show QGIS's extendibility by these providers being plugins (i.e. "Look at what you can easily add to QGIS!"). Not to toot my own horn, but I think my QEP should be a goal (or something to consider) for 4.0.
Might I suggest if there's a release planned before 4.0, in the release prior, start warning the users but still have SAGA, and in 4.0 drop it.
@nyalldawson do you think we should try to move this forward?
@alexbruy Yes, I think so.
I would suggest the next step would be for us to consolidate the two unofficial plugins into a single "recommended" replacement. Do you have any thoughts there? (I'm honestly happy whichever way we decided to go)
I would suggest the next step would be for us to consolidate the two unofficial plugins into a single "recommended" replacement.
@nyalldawson @alexbruy that was one of my concerns (not offering a "recommended" replacement), but if you are on board with that then let's move forward! I look also forward to help with that plugin with description files.
QGIS Enhancement: Officially drop support for the SAGA provider (without removing it), show warning to all users when running SAGA tools
Date 2021/08/08
Author Nyall Dawson (@nyalldawson)
Contact nyall dot dawson at gmail dot com
Version QGIS 3.22
Summary
The SAGA Processing provider has been a constant source of conflict since it was introduced in QGIS 2.x. Despite our best efforts, we CAN'T offer users a first class, well supported experience with this provider.
Recent QGIS versions officially support only SAGA 2.3 LTR, and show a user-facing warning whenever users try to run SAGA tools with SAGA 7.
I propose that we extend this warning and show it regardless of the SAGA version, advising users that the provider is now officially unsupported by QGIS and will be moved to a 3rd party plugin in QGIS 4.0.
This gives users a clear indication that the experience of running SAGA algorithms in QGIS is not optimal, and that it's now a "use at own risk" tool. It also gives users plenty of warning that the responsibility for testing and evaluating the results of these tools is their responsibility. Lastly, it gives users plenty of notice that the provider will be removed in future.
Note that there are currently two community supported plugins which offer alternative means to run SAGA tools in processing:
For many years these have been the recommended tools to use for users wanting to run SAGA in processing.
Proposed Solution