Hi devs,
Vaclav Petras <notifications@github.com> schrieb am Mi., 9. Juni 2021, 05:22:
…anyway, I think the ultimate fix is to build usable images from GRASS source code without a 3rd party library which is not an official dependency. Either GRASS needs grass-session to work and then it should be part of the source code or GRASS should be fixed to work without it.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub,
Following this comment I’d like to open the discussion: also in my view we need to make grass-session part of core. And that in a way that it can be split out easily as a pip package or whatever appropriate.
Opinions are welcome!
Best
Markus
Hi,
Appreciate the discussion!
I also agree with Vasek here.
GRASS session is very useful, esp. in standalone python scripts or when using GRASS in Jupyter notebooks, or maybe in QGIS Processing for that matter….
However, since grass-sessions is an external Python module it has had issues due to version changes before.
So, a big +1 from my side to include it in core, knowing that my ability to contribute here with coding is very limited…
Being able to just do
import grass
would be nice indeed, but I am not sure if it is feasible to throw an informative error message if users try to use GRASS functions without a running session…
That said, what would the gain of a pip package be? If you install GRASS you would have the functionality. If you did not install GRASS you could not use a pip package with grass-session like functionality anyway, no?
Cheers
Stefan
···
From: grass-dev grass-dev-bounces@lists.osgeo.org On Behalf Of Markus Neteler
Sent: onsdag 9. juni 2021 08:55
To: GRASS developers list grass-dev@lists.osgeo.org
Subject: [GRASS-dev] grass-session integration into core
Hi devs,
Vaclav Petras <notifications@github.com> schrieb am Mi., 9. Juni 2021, 05:22:
…anyway, I think the ultimate fix is to build usable images from GRASS source code without a 3rd party library which is not an official dependency. Either GRASS needs grass-session to work and then it should be part of the source code or GRASS should be fixed to work without it.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub,
Following this comment I’d like to open the discussion: also in my view we need to make grass-session part of core. And that in a way that it can be split out easily as a pip package or whatever appropriate.
Opinions are welcome!
Best
Markus
On Wed, Jun 9, 2021 at 3:27 AM Stefan Blumentrath <Stefan.Blumentrath@nina.no> wrote:
…I am not sure if it is feasible to throw an informative error message if users try to use GRASS functions without a running session…
If you run without the runtime environment (modules are not on path), we could catch FileNotFoundError in grass.script.start_command() and re-raise or raise a different exception based on the presence of environmental variables (such as GISBASE) to help user debug it, although a troubleshooting or FAQ section may have the similar effect.
If you somehow manage to run with the runtime, but without the db/location/mapset thingy being open/current, you currently get some complaint from modules about a LOCATION variable not being defined which is cryptic, but can be improved.
That said, what would the gain of a pip package be? If you install GRASS you would have the functionality. If you did not install GRASS you could not use a pip package with grass-session like functionality anyway, no?
I don’t see advantages in a pip package like this either. It would be a similar scenario as now except that the version sync is better and that it shows the weirdness of grass-session better: Let’s say you build GRASS in a Docker image. Then, you run pip on part of the source code in order to make the thing you just built actually work!? Why isn’t the grass-session package installation part of the build if it is needed anyway to make GRASS work?