[GRASS-git] [OSGeo/grass] fb6729: init: Enable subcommands for the main grass comman...

[Vaclav Petras]

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

  Changed paths:
    M lib/init/grass.py

  Log Message:
  -----------
  init: Enable subcommands for the main grass command (#6442)

This enables access to the subcommands from the main _grass_ command.

It keeps the commands not documented at the top level, so they remain hidden and experimental.

Backwards compatibility with the classic CLI parameters should be smooth. The decision is based on the first command line argument. This will yield unexpected results (only) when path to mapset matches one of the subcommands, e.g., when naming mapset simply mapset and running the _grass_ command in the project directory which contains this mapset (same for project). It may become a bigger issue with more subcommands, but a simple workaround is prefixing the path `./`.

This includes subcommands which are in other PRs, but the subcommand parser will deal with that by reporting an error. This could be an approach we take in general: reserving subcommand names even when we don't have them implemented yet (and triggering some of the directory (project, mapset, filename) issues sooner (even before a specific subcommand is fully introduced).

This will is useful together with project create subcommand (#6441) and raster pack IO (#5877).

Before (assuming PYTHONPATH or FHS): python -m grass.app run --crs EPSG:3358 g.proj -p

After (assuming PATH): grass run --crs EPSG:3358 g.proj -p



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