init: Enable subcommands for the main grass command #6442
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This enables access to the subcommands from the main command. It keeps the commands not documeneted at the top level, so they remain hidden and experimental. The lock and unlock, now under 'grass mapset lock' and 'grass mapset unlock', are accessible from outside of GRASS through CLI (no Python API or GRASS tools), providing a way of other applications (such as QGIS) to use GRASS locking when accessing GRASS mapsets. Given that lock and unlock are under mapset (they are too low level to be at subcommand top level), it is clear there should be also project. The create_project function is readily available for CLI use (espetially after OSGeo#6415), so it is now under 'grass project create' and the subcommand is utilized in tests. For symmetry, this adds also 'grass mapset create' which uses the semi-internal function grass.grassdb.create.create_mapset. The function parameters were adjusted to allow for a single path being provided (which was already supported through path resolution function). The create_project function was also improved by adding description parameter as full word replacing (but keeping) desc parameter. The behavior was sligtly changes so that MYNAME is only created when description is provided which is what the documenetation suggests ('desc...creates MYNAME file'), but it was implemented that MYNAME was always created even if empty. Finally, missing documentation for the CRS parameter was added. The new structure in the cli file is that project and mapset subcommand parser definitions have their own functions. This minimizes name conflicts and keeps the main function short. Finally, 'grass run' subcommad now has --project to use an existing project (defaulting to PERMANENT mapset) or a mapset within that project. This is needed now for testing the created project using the subcommand interface.
…not desc in tests.
wenzeslaus
changed the title
petrasovaa
reviewed
Oct 3, 2025
This was referenced Oct 4, 2025
petrasovaa
approved these changes
Oct 6, 2025
Contributor
petrasovaa
left a comment
petrasovaa
left a comment
There was a problem hiding this comment.
This is a great step especially given GDAL has recently added subcommands.
wenzeslaus
added a commit
that referenced
this pull request
Oct 6, 2025
The lock and unlock subcommands are operating on a mapset and are low-level (they specifically just lock and unlock and don't do anything with any session). So, this is moving them under a new top-level subcommand mapset (from #6462). With the lock subcommands being accessible outside of GRASS through CLI without a Python API or a GRASS tools (with or without #6442), other applications which can call subprocesses (such as QGIS) can use GRASS locking when accessing GRASS mapsets. This is using the new structure in the cli.py file with parser definitions having their own functions (minimizing name conflicts between parses and keeping the main function short). Additionally, the interface and execution code are placed together because they would be changed at the same time. Tests now test locking the the default mapset and a separate mapset in a smoke test fashion (more in-depth tests exist in the Python API). Example: grass mapset lock /tmp/project_1/work_2
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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).
Before
python -m grass.app run --crs EPSG:3358 g.proj -p python -m grass.app mapset lock /path/to/mapset # mapset subcommand is in different PRAfter
grass run --crs EPSG:3358 g.proj -p grass mapset unlock /path/to/mapset # mapset subcommand is in different PRCommit message
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