Drop Official Support for GRASS C++ Plugin
PeterPetrik opened this issue · comments
QGIS Enhancement: Drop GRASS C++ Plugin
Date 2021/10/05
Author Peter Petrik (@PeterPetrik )
Contact peter dot petrik at lutraconsulting dot co dot uk
maintainer @PeterPetrik
Version QGIS 3.24+
Summary
Maintained GRASS Processing Provider and the modern GRASS-GIS covers the functionality that was previously covered by native C++ GRASS Plugin
Currently, the code section receives minimal attention from the developers. Also, it is not fixed in the regular bug-fix sprints before releases (at least from 2019 we reply to issues to use QGIS Processing and that plugin is unmaintained).
Proposed Solution
From QGIS 3.24:
- Change title/description in Plugin Manager to "GRASS 7 (not officially supported)" or similar
- Close all open bugs filed against the GRASS Plugin with a notice that it is officially unsupported, and direct them to the GRASS-GIS and GRASS QGIS Processing. Similarly, we immediately close any newly opened reports against the GRASS Plugin with the same message.
- Add CMake option (
-DWITH_GRASS_PLUGIN) to be able to build QGIS with GRASS but without Plugin
From QGIS 4.0
- remove C++ GRASS Plugin.
Affected Files
https://github.com/qgis/QGIS/tree/master/src/plugins/grass
Further Considerations/Improvements
- no maintenance of the code
- improves compilation speed
- helps packagers
Backwards Compatibility
n/a
Issue Tracking ID(s)
Votes
ping @blazek
It seems no one wants to comment this first :) So I take my chance here, and I vote yes. If this will happen it will be an important moment without doubt, but give the state of the GRASS plugin (not maintained) and the fact that it has lost most of its importance since we can run GRASS tools in Processing (even if they are slow with large datasets, because of the in/out to/from GRASS locations/mapsets done on the fly at each run of a GRASS tool). Also I'm not sure than anyone has ever used the GRASS vector editing capabilities and styling (but maybe that would not be part of the removal of the plugin?). What is important is to keep the ability to read GRASS locations/mapsets and use the GRASS layers as normal inputs in QGIS tools. Not sure if is compatible with the removal but it would be very nice to be able to launch a GRASS console from within QGIS (but as it is part of the GRASS plugin functionality I understand that maybe this will not be possible).
There is GRASS plugin and GRASS vector/raster provider. It should be clarified if this proposal is about plugin only or about both plugin and providers.
because of the in/out to/from GRASS locations/mapsets done on the fly
If I recall, there is work being done in GRASS to fix this. There supposedly is a plan (I think in GRASS 8) to remove the need to create a location and mapset.
@blazek
It appears to be referring to the plugin, not the provider.
yep, this is only about plugin. Provider & processing should is not part of this QEP
So I would say a super-safe approach could be this:
- Allow GRASS processing algorithms to be run DIRECTLY on grass layers (either those loaded in the project, or by selecting "browse for layer" and expanding out a grass map set directory). Similarly allow the results to be stored as their original grass datasets, without conversion to other formats.
- Move the functionality to create a new grass mapset/layer from out of the grass plugin to to the grass provider's browser provider. (currently you have to have the plugin enabled in order to create a new mapset).
We could then safely drop the plugin without any minimal loss of functionality -- the algorithms would be available via processing, and just like the plugin versions could be run directly as "pure" grass tools. Users could still create/load grass layers into projects too (as the grass provider will remain), and interact/manage them via the browser.
The only lost functionality then that I can see is that the interactive console would be dropped.
@nyalldawson That sounds like a very reasonable approach to me and in fact as a enhancement (and not just a loss in functionality).
@esnyder-rve I am not aware of any plan to drop the location/mapset concept (apart form discussions on terminology). That said, there are some also new features in GRASS 8 that can speedup the current processing approach quite a bit...
So a question for me is, what is the time frame for this QEP? As GRASS 8 is approaching, it might be good to coordinate, but only is schedules match I guess...
I am not aware of any plan to drop the location/mapset concept (apart form discussions on terminology). That said, there are some also new features in GRASS 8 that can speedup the current processing approach quite a bit...
Thank you for clarifying. I saw the FOSS4G 2021 GRASS progress presentation on YouTube shortly after writing that. I had thought they were dropping those concepts, but they're just cleaning up the startup process.
As GRASS 8 is approaching, it might be good to coordinate, but only is schedules match I guess
@ninsbl side question, would the GRASS project take over the management and maintenance of the GRASS plugin for the QGIS/Processing toolbox?
As GRASS 8 is approaching, it might be good to coordinate, but only is schedules match I guess
@ninsbl side question, would the GRASS project take over the management and maintenance of the GRASS plugin for the QGIS/Processing toolbox?
Just to avoid any ambiguity here (as the ticket is about removing the plugin) could you explain what exactly you mean by "GRASS plugin for the QGIS/Processing toolbox" ? You mean the GRASS processing provider ?
Just to avoid any ambiguity here (as the ticket is about removing the plugin) could you explain what exactly you mean by "GRASS plugin for the QGIS/Processing toolbox" ? You mean the GRASS processing provider ?
@mlennert the GRASS Processing provider has been recently separated into a (core) QGIS plugin (as well as the SAGA one and OTB)
https://github.com/qgis/QGIS/tree/master/python/plugins
also because there is the plan (for QGIS 4 I think/hope) to move non native providers out of QGIS. See for example #226
This will leave up in the air who will take care of such plugins (something that will need some discussion before it happens), where the ideal scenario (in my opinion) would be the original projects take care of them.
Thanks for the clarification @gioman. IIRC the decision at the time was that GRASS was considered sufficiently central to be maintained by the QGIS team. So this is up for discussion again ?
So this is up for discussion again ?
I'll leave the main Processing developers and maintainers to intervene here :) @alexbruy @nyalldawson
IIRC the decision at the time was that GRASS was considered sufficiently central to be maintained by the QGIS team.
It hasn't been decided fully yet. I personally think GDAL + GRASS are too valuable (and are sufficiently low maintenance) to move out of the default install, but I believe @alexbruy would like to see this happen.
In the specific case of the GRASS algorithms, we've always seen a very nice steady stream of contributions from the community adding fixes and new GRASS algorithms. And that's even with the code sitting in the main QGIS repo, with all the learning curve and difficulties associated with contributing to that!
Based on this I don't think there'd be any need for the actual GRASS team to take up maintenance of this code, and have full confidence in the wider QGIS user community's ability to maintain it.
(as opposed to say the SAGA algorithms, where no-one in the QGIS user community seems interested in contributing anything aside from complaints when things break 🙃 )
I believe @alexbruy would like to see this happen.
I fully agree that there is no sense in moving GDAL from the default install, as QGIS anyway depends on GDAL and this provider is well-tested and maintenance overhead is low.
However, I don't have strong opinion about GRASS provider. Maybe having it as a 3rd party plugin will give users and developers more freedom. I mean this way it can be updated independently from QGIS and more closely follow development of the upstream project. But pushing it out of the default install is not my goal and I have nothing against having well-maintained provider in the core. Especially now when it is already a separate plugin whose breakage will not affect Processing functionality.
In case if we decide to move GRASS out of the QGIS, I will be happy to give a hand with maintenance.
I would like to note that this proposal is only and only about the GRASS plugin. My proposition was to drop unmaintained GRASS plugin. GRASS provider, GRASS processing plugin and definitely SAGA or GDAL is out of the scope of this QEP
:)