grass
grass copied to clipboard
OSGeo
[Bug] Issue in C code any Python environment interplay
When running i.maxlik from GUI, its UI works fine. When running from command line (terminal not GUI one), module UI fails to start with an error on system being not initalized (G_gisinit() not called).
The issue can be fixed with plain from grass.lib import gis in gselect.py but it seems to be a hack as code should work in its current form.
https://github.com/OSGeo/grass/blob/1961472afeb7633c9b744b0a60c923fb9b1d4411/gui/wxpython/gui_core/gselect.py#L2825
git bisect indicates on 8e66baaf5e752dc2e9050bc1d888bb3391f1aaad (PR #2202) being to blame but it more seems to just uncover underlying issue than being the cause itself.
As for the underlying issue, I think the best solution would be to avoid direct C calls from the GUI. This would be hard to do for cases like NVIZ, but here, the code is just listing things. Separate C or Python modules are a straightforward way of creating an intermediate layer; temporal framework uses a more complex solution with creating that intermediate layer as Python API.
Another way of looking at this is that all functionality useful outside of C modules, should be accessible through modules. These modules can then be used in GUI unless it turns out that it does not work for performance reasons or some data manipulation issues.
I do not see any problem of intermingling C calls in GUI in broad terms. If environment initialization happens properly, there shouldn't be any problem with it. In this particular case – I do agree – a module managing signature files would be good. Although question if it should be a separate module or new functionality of already existing g.* modules is not closed yet. I managed to get down to the root of this issue. pygrass modules have calls to G_gisinit("") and thus plain import performs initialization. In case of parser starting GUI, there might be no calls to G_gisinit from python been made. Thus a simple solution is just to call G_gisinit when forms.py is run standalone.
I do not see any problem of intermingling C calls in GUI in broad terms.
The library is currently following the idea that it is used primarily in processing tools, not persistent applications. So, the question is if we want to use it in GUI and then try to catch up in the library or try to avoid using it and improve the library first.
If environment initialization happens properly, there shouldn't be any problem with it.
That is an issue in the GUI since it is hard to determine what is the initialization order due to functions being called based on user action and due to multiple executable files being involved. Currently, there is no provider or manager object in the API which would ensure things are happening in the right way.
Although question if it should be a separate module or new functionality of already existing g.* modules is not closed yet.
I would go with separate module(s). Signature files have things specific just to them which would complicate aligning them with e.g. raster maps in g.list. In other words, I would add add them to existing modules only if it is clear that this will not complicate interface or code of the existing modules. A standalone prototype might be a good way of figuring it out anyway.
@rajdeepdas2000 Which aspect of it? See the PR already opened for this. The PR is not ideal in my view because it assumes the the import will be successful, so that's perhaps one reason why it is not merged yet.
A more elaborate solution is to reduce the direct library calls by creating a standalone command line tool (aka module) which will wrap the C functionality (see my notes on that above).