[Bug] grass -c and interaction with python wrappers

[laurapoggio-sptools]

Describe the bug

I am using this code to create a new project from bash:
grass -c EPSG:3035 -e ./GRASSDATA/.

I get this error:

ERROR: No CRS is needed for creating mapset <GRASSDATA>, but <EPSG:3035> was provided as CRS. Did you mean to create a new project?

This is happening on a docker image with Debian13

System description

Base operative system: debian:trixie-slim

grass --version GRASS GIS 8.4.1
gdalinfo --version GDAL 3.11.3 "Eganville", released 2025/07/12
proj --version Rel. 9.6.2, June 4th, 2025
geos-config --version 3.13.1
python --version Python 3.13.5

Additional context

It was difficult to pinpoint the causes of the problem. However we found out it is somehow related to python wrappers.
The solution was to create a wrapper script around grass command that:

• Detects -c (new project creation) and disable python paths
• unset of python envs: PYTHONPATH, PYTHON, GRASS_PYTHON, PYTHONHOME, PYTHONUSERBASE,PYTHON3PATH etc
• Runs project creation and re-sets python envs
• If NOT -c then it goes ahead with execution of command

Building grass --without-python also solves the problem but the python modules are then missing.

@jorgejesus FYI

[wenzeslaus]

Analysis of path handling and creation behavior

I'm able to get the same message with the following workflow on a local machine (no Docker):

$ # ./grassdata does not exist and we use it in creation
$ grass -c EPSG:3035 -e ./grassdata
Creating new GRASS project <grassdata>...
$ # ./grassdata was at the end of the path, so GRASS picks it a the project name
$ # (many users put their main projects into a `~/grassdata`, so that may create confusion here
$ # but other than that, everything works as expected)
$ # The directory exists and is set up as a GRASS project
$ ls grassdata/
PERMANENT
$ # Repeating the same command as above fails as expected:
$ grass -c EPSG:3035 -e ./grassdata
ERROR: Unable to create new project because the project <grassdata> already exists.
Exiting...

So far so good, let's do something different.

$ # Let's cd into that project:
$ cd grassdata/

Let's execute exactly the same command as above, but now it runs in context of the existing project. So the relative path ./grassdata actually is .../grassdata/grassdata.

$ # Requesting creation with EPSG and relative path ./grassdata
$ grass -c EPSG:3035 -e ./grassdata
ERROR: No CRS is needed for creating mapset <grassdata>, but <EPSG:3035> was provided as CRS. Did you mean to create a new project?

$ # Just to be clear, the relative path here works the same way elsewhere
$ # so same result without the explicit ./
$ grass -c EPSG:3035 -e grassdata
ERROR: No CRS is needed for creating mapset <grassdata>, but <EPSG:3035> was provided as CRS. Did you mean to create a new project?
$ # ...or with an trailing slash. It is processed as path, so all these are equivalent.
$ grass -c EPSG:3035 -e grassdata/
ERROR: No CRS is needed for creating mapset <grassdata>, but <EPSG:3035> was provided as CRS. Did you mean to create a new project?
$ # Yes, even a trailing dot is still the same path (it simply says current path).
$ grass -c EPSG:3035 -e grassdata/.
ERROR: No CRS is needed for creating mapset <grassdata>, but <EPSG:3035> was provided as CRS. Did you mean to create a new project?

GRASS thinks we want to create a mapset, because we provided a path to an existing project (the current directory we are in referred to from the relative path).

$ # Requesting creation with just the directory
grass -c -e ./grassdata
Creating new GRASS mapset <grassdata>...

Here, the directory referred to is still .../grassdata/grassdata just like before, so a directory under an existing project, but because we are not providing EPSG, GRASS now understands that we want to create a mapset, so it proceeds in creating it.

The directory tree now looks like this:

$ pwd
/tmp/grassdata
$ tree
.
├── grassdata
│   ├── sqlite
│   ├── VAR
│   └── WIND
└── PERMANENT
    ├── DEFAULT_WIND
    ├── ...
    └── WIND

5 directories, 10 files

Next steps

Can you please run tree, ls, and pwd to explore what is in the file system before you execute grass -c EPSG:3035 -e ./GRASSDATA? (Please, shere the actual commands and their full outputs.)

[laurapoggio-sptools]

This are the commands and the outputs:

$ pwd
/grassdata

$ ls
[empty output]

$ tree
.

0 directories, 0 files

[wenzeslaus]

...and what is the output now when you execute grass -c EPSG:3035 -e ./grassdata?

You can also try to execute grass -c EPSG:3035 -e /grassdata given that ./grassdata and /grassdata look very similar, but are very different and you have both.

Just to be clear, I can't really tell without all the commands and outputs what is happening on that machine or container, but I can explore and execute any commands you share.

[laurapoggio-sptools]

Apologies, I realised I forgot to link the original discussion from the discourse : https://discourse.osgeo.org/t/error-when-creating-a-new-project/149219

Outputs of commands:

1. Container with the issue reported and without the workaround described: error as reported

$ grass -c EPSG:3035 -e ./test_grass/
ERROR: No CRS is needed for creating mapset <test_grass>, but <EPSG:3035> was provided as CRS. Did you mean to create a new project?

2. Container with the details provided above and with he workaround described above : no issues

$ grass -c EPSG:3035 -e ./test_grass/
Creating new GRASS GIS project <test_grass>...

3. Other container with same libraries but almalinux as base operative system: no issues

$ grass -c EPSG:3035 -e ./test_grass/
Creating new GRASS GIS project <test_grass>...

Thanks!

[wenzeslaus]

I can't reproduce this:

Container:

$ docker run --network=host -it debian:trixie-slim

Inside the container:

root...:/# apt update
...
root...:/# apt install grass
...
# grass --version
GRASS GIS 8.4.1
...
root...:/# grass -c EPSG:3035 -e ./test_grass/
ERROR: GRASS GIS database directory, project and mapset not set properly. Use GUI or command line to set them.
Exiting...

Maybe not an ideal message for the situation, but otherwise it works, so let's try some other dir than /:

root...:/# ls
bin   dev  home  lib64	mnt  proc  run	 srv  tmp  var
boot  etc  lib	 media	opt  root  sbin  sys  usr
root...:/# cd home/
root...:/home# ls
root...:/home# mkdir test
root...:/home# cd test/
root...:/home/test# ls
root...:/home/test# grass -c EPSG:3035 -e ./test_grass/
Creating new GRASS GIS project <test_grass>...

That works, so I again try to create the situation to produce the message:

root...:/home/test# cd test_grass/
root...:/home/test/test_grass# grass -c EPSG:3035 -e ./test_grass/
ERROR: No CRS is needed for creating mapset <test_grass>, but <EPSG:3035> was provided as CRS. Did you mean to create a new project?
Exiting...

...and that works as expected since the project (called test_grass) already exists and we seem to be trying to create a mapset inside it (mapset called test_grass on path /home/test/test_grass/test_grass).

root...:/home# apt install tree
root...:/home# cd /home/
root...:/home# tree
.
`-- test
    `-- test_grass
        `-- PERMANENT
            |-- DEFAULT_WIND
            ...
            |-- WIND
            `-- sqlite

5 directories, 8 files

Let me know if you have the commands to reproduce your issue. Plain image is fine for me, so perhaps you have more software there? Is there something else called "grass"? What does find / -name grass say? Is there something suspicious in output of find / -path "*/grass/*"? Can you confirm you are getting the error right now with the file system state you posted? Can you reproduce my workflow?

[laurapoggio-sptools]

The container was created with a lot of softwares and optimisations. All libraries (gdal, geos, proj) and grass were compiled from source not installed from repositories or binaries.

We debugged this in quite a bit of details. It was a compilation option that created the issue, because with other containers with different compilation options for python, grass, gdal, geos and proj we did not have the same issue.

The issue is most likely releated to python wrappers because, when we compile with the same options but without python, the error does not appear.

I am sorry if all the previous debugging history was not clear when I opened this bug report.
I can see if I can upload the image with the issue to dockerhub ( I need to remove some data that are in the image for privacy reasons, so it is no a simple "push")

[wenzeslaus]

I can pull an image from DockerHub if that sounds like a reasonable option to you. Otherwise, it seems very localized to me, and I don't have much to go with. Also a lot of the code actually changed as the discussion mentions, but a lot only only after the 8.4 release, so compiling from the main branch would be actually something to try. There is a change pending right now in #6393 related to paths. However, I don't see a possible mechanism how any of that would influence the evaluation of the file paths, so I can't make any promises on the changes making things better.

The --without-python does not make sense to me. If you look into the source code, this compile option is no longer present in 8.4 (grep -IrnE "with(out)?-python" does not give much). If I recall correctly, it was used drive a build of a specific binary which liked to Python C libraries, so the whole thing was unrelated to how the grass command uses Python and the grass Python package.

[laurapoggio-sptools]

This is actually very helpful, because I know that there were some optimisations done on the C libraries (even if not specifically for GRASS). Let me check with my colleague and we will get back here. Thanks!

[laurapoggio-sptools]

The solution for this specific case was to remove the --with-python from the compilation instructions.

However, I am still puzzled because I am using it in other containers with different initial operative system (as a test) and I am not getting any problems.

Thanks