[GRASS-git] [OSGeo/grass] 4541e2: grass.app: Do env var setup in RuntimePaths (#6482)

[Vaclav Petras]

  Branch: refs/heads/main
  Home:   https://github.com/OSGeo/grass
  Commit: 4541e23b3f4350c8a47a3098181f0fb2b055ef6c
      https://github.com/OSGeo/grass/commit/4541e23b3f4350c8a47a3098181f0fb2b055ef6c
  Author: Vaclav Petras <wenzeslaus at gmail.com>
  Date:   2025-10-17 (Fri, 17 Oct 2025)

  Changed paths:
    M lib/init/grass.py
    M python/grass/app/runtime.py
    A python/grass/app/tests/grass_app_resource_paths_test.py
    R python/grass/app/tests/grass_app_runtime.py
    A python/grass/app/tests/grass_app_runtime_test.py
    M python/grass/script/setup.py
    M python/grass/script/tests/grass_script_setup_test.py

  Log Message:
  -----------
  grass.app: Do env var setup in RuntimePaths (#6482)

In anticipation of #5630 which adds multiple variables besides GISBASE, this modifies RuntimePaths to handle variables from a list (dict to be exact). Now, only one variable is handled that way and that is GISBASE. The GRASS_PREFIX variable is handled in a different way because the compile-time values of the other variables are without a prefix and the RuntimePaths is prefixing them when the variable is needed.

The RuntimePaths object can now set environment variables when explicitly asked to do so. This hides the info about all the variables handled by the object inside the class code, so the caller does not need to know about a change from one GISBASE to multiple GISBASE-like variables. Both the main grass executable and the Python init function now use RuntimePaths to set up the GISBASE (and other GISBASE-like variables in the future).

While both usages of RuntimePaths are similar, they are not completely the same. Python init takes optional, caller-provided gisbase which is used as a prefix (assuming prefix and gisbase are, in practice, the same), while the main executable always uses the RuntimePaths default. Both test if the gisbase from RuntimePaths exists, and if not, they go to get_install_path to get a fallback one.

To allow for the fallback to take effect, RuntimePaths can take prefix in the constructor and will use it instead of the compile-time determined GRASS_PREFIX. Additionally, allow mixing of gisbase and prefix-only on the input which is needed for real installations, at least those without FHS. If the path is full GISBASE, the unique GISBASE part is removed, remove it to get the prefix only. The corresponding test passes with non-trivial GISBASE. Also, the consistency tests fail when the compile-time prefix path is non-sense.

For simple, and more readable code, avoid import alias for resource_paths and use the module name directly.

The actual init code needs to unfortunately deal with GISBASE directly. RuntimePaths itself always assumes that the paths are right, so any searches and fallbacks need to happen in the caller code. When we provide a corrected gisbase as a prefix, a broken build will supply wrong gisbase to the prefix breaking gisbase again, so we need to manually fix it with a subsequent call. This is not nice, and we need to have it at two different places now, but it is not a overly complicated code.

Generally, the tests are trying to check that resource paths are substituted during build and fail otherwise, i.e., the opposite of what the code is trying to do which is work even if the installation is broken in some way.



To unsubscribe from these emails, change your notification settings at https://github.com/OSGeo/grass/settings/notifications