grass
grass copied to clipboard
lib/init: add GRASS_CONFIG_DIR environment variable
GRASS_CONFIG_DIR variable allows to set alternative root path for
.grass<VERSION> configuration directory. If not set, $HOME directory
is used.
The main use case of this PR is to be able to run multiple isolated instances of grass. Using $HOME or $XDG_CONFIG_HOME variables to force grass to store configuration in alternative directory is not a good idea, because this will also have an impact on other tools relying on those variables. That's why I introduced a new grass specific environment variable.
/cc @landam
Related #3153
Would it be possible to, instead of introducing another GRASS env var, adopt our code to respect (if set) $XDG_CONFIG_HOME (see https://specifications.freedesktop.org/basedir-spec/basedir-spec-0.6.html)?
Would it be possible to, instead of introducing another GRASS env var, adopt our code to respect (if set) $XDG_CONFIG_HOME (see https://specifications.freedesktop.org/basedir-spec/basedir-spec-0.6.html)?
The main use case of this PR is to be able to run multiple isolated instances of grass. Using $HOME or $XDG_CONFIG_HOME variables to force grass to store configuration in alternative directory is not a good idea, because this will also have an impact on other tools relying on those variables. That's why I introduced a new grass specific environment variable.
Would it be possible to, instead of introducing another GRASS env var, adopt our code to respect (if set) $XDG_CONFIG_HOME (see https://specifications.freedesktop.org/basedir-spec/basedir-spec-0.6.html)?
But I agree, that usage of XDG_CONFIG_HOME instead of HOME is a good fix for https://github.com/OSGeo/grass/issues/3153 .
The main use case of this PR is to be able to run multiple isolated instances of grass. Using $HOME or $XDG_CONFIG_HOME variables to force grass to store configuration in alternative directory is not a good idea, because this will also have an impact on other tools relying on those variables. That's why I introduced a new grass specific environment variable.
I see.
I will not be able to look at and test this this week, but please hold on, I see there are Mac specific changes now that need hands-on testing/review.
I will not be able to look at and test this this week, but please hold on, I see there are Mac specific changes now that need hands-on testing/review.
Sure. This PR shouldn't change behaviour compared to #3694.
As for the implementation, there is couple of other places which may need fixing. g.extension needs to do something, but I didn't
@wenzeslaus I just found this f6ac969:
The installation of addons seems to respect GRASS_CONFIG_DIR variable already:
rm -rf /tmp/.grass8/
GRASS_CONFIG_DIR=/tmp bin.x86_64-pc-linux-gnu/grass ~/grassdata/world_latlong_wgs84/PERMANENT/ --exec g.extension r.hydrodem
ls /tmp/.grass8/addons/bin/
and
rm -rf ~/.grass8/
bin.x86_64-pc-linux-gnu/grass ~/grassdata/world_latlong_wgs84/PERMANENT/ --exec g.extension r.hydrodem
ls ~/.grass8/addons/bin/
Result in the both cases is:
r.hydrodem
@nilason Currently MacOS CI fails with
ERROR: Failed to create configuration directory '/Users/runner/Library/GRASS/8.5' with error: No such file or directory
which is triggered by https://github.com/imincik/grass/blob/config-dir-env-variable/lib/init/grass.py#L404
The path (/Users/runner/Library/GRASS/8.5) seems to be correct according grass.py@main: https://github.com/OSGeo/grass/blob/main/lib/init/grass.py#L413
Any idea why CI is failing?
examine what.
lib/gis/home.cworries me a little bit as it seems to figure out the path as well, at this point duplicating what is in Python which is more complex code with this PR and the anticipated XDG change.
@wenzeslaus This issue should be solved by ed4b4a8b11.
Right, the G_config_path() should be also synced with Python code (especially related to MacOS - but this is not related to this PR and should be solved by a new separated PR).
Tested by db.login which uses G_config_path():
bin.x86_64-pc-linux-gnu/grass ~/grassdata/world_latlong_wgs84/PERMANENT/ --exec db.login use=x pass=y --overwrite
The password was stored in file (/home/martin/.grass8/dblogin)
GRASS_CONFIG_DIR=/tmp bin.x86_64-pc-linux-gnu/grass ~/grassdata/world_latlong_wgs84/PERMANENT/ --exec db.login use=x pass=y --overwrite
The password was stored in file (/tmp/.grass8/dblogin)
@nilason Currently MacOS CI fails with
ERROR: Failed to create configuration directory '/Users/runner/Library/GRASS/8.5' with error: No such file or directorywhich is triggered by https://github.com/imincik/grass/blob/config-dir-env-variable/lib/init/grass.py#L404
The path (
/Users/runner/Library/GRASS/8.5) seems to be correct according grass.py@main: https://github.com/OSGeo/grass/blob/main/lib/init/grass.py#L413Any idea why CI is failing?
It works with:
diff --git a/lib/init/grass.py b/lib/init/grass.py
index 244786d891..8fc6009198 100755
--- a/lib/init/grass.py
+++ b/lib/init/grass.py
@@ -401,7 +401,7 @@ def create_grass_config_dir():
if not os.path.isdir(directory):
try:
- os.mkdir(directory)
+ os.makedirs(directory)
except OSError as e:
# Can happen as a race condition
if not e.errno == errno.EEXIST or not os.path.isdir(directory):
os.makedirs is needed because the /Users/runner/Library/GRASS also must be created with a fresh installation.
(The GUI issue I encountered is most likely unrelated to this PR and I'll file an Issue or PR to address that).
Now I see I'm not alone, already reported with #4091.
@wenzeslaus if you have no objections, we can merge this PR. Please can you update your review?
This seems to have broken the Docker workflow https://github.com/OSGeo/grass/actions/runs/10218758009.
This seems to have broken the Docker workflow https://github.com/OSGeo/grass/actions/runs/10218758009.
See https://github.com/OSGeo/grass/pull/4130