[GRASS-dev] [GRASS GIS] #3967: Add batch job example without path

#3967: Add batch job example without path
-------------------------+-------------------------
Reporter: jidanni | Owner: grass-dev@…
     Type: enhancement | Status: new
Priority: trivial | Milestone:
Component: Docs | Version: unspecified
Keywords: | CPU: Unspecified
Platform: Unspecified |
-------------------------+-------------------------
On https://grass.osgeo.org/grass79/manuals/grass7.html all the batch job
examples have
  /path/to/grassdata/test1/PERMANENT/
in them. Please add at least one simple example,
  grass --exec v.info map=abc
without it too. Works just fine.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3967&gt;
GRASS GIS <https://grass.osgeo.org>

#3967: Add batch job example without path
--------------------------+------------------------------------
  Reporter: jidanni | Owner: grass-dev@…
      Type: enhancement | Status: new
  Priority: trivial | Milestone:
Component: Docs | Version: unspecified
Resolution: | Keywords: grass.py exec CLI init
       CPU: Unspecified | Platform: Unspecified
--------------------------+------------------------------------
Changes (by wenzeslaus):

* keywords: => grass.py exec CLI init

Comment:

Actually, I did not include it into documentation intentionally, but did
not disable it - a dirty trick. I don't know if it is a good idea to do
this, but it might be useful for some. Generally speaking, why would you
like to run a batch job with whatever was the last used mapset? Of course,
`--exec` is meant to be used more broadly than just batch jobs, but still
it seems to me that specifying full path is appropriate.

If you would be using GRASS GIS only with `--exec`, this may not work as
expected because `--exec` actually does not save the path (to a file in
`~/.grass7`), so the next call is using path from an interactive session
(in GUI or with `--text`).

What you can do now is a workflow like this:

{{{
grass grassdata/location/mapset -c EPSG:3358 -e
grass grassdata/location/mapset --exec r.import input=some_image.tif
output=some_image
grass grassdata/location/mapset --exec r.info some_image
grass grassdata/location/mapset --exec r.mapcalc "improved_image = 5 *
some_image"
grass grassdata/location/mapset --exec r.out.gdal input=improved_image
output=.../improved_image.tiff
}}}

I think you are suggesting you want a workflow like this:

{{{
grass grassdata/location/mapset -c EPSG:3358 -e
grass --exec r.import input=some_image.tif output=some_image
grass --exec r.info some_image
grass --exec r.mapcalc "improved_image = 5 * some_image"
grass --exec r.out.gdal input=improved_image
output=.../improved_image.tiff
}}}

It seemed to be that `--exec` probably should not behave like that, so
e.g. in #2579 (under Additional ideas), I suggested a subcommand
directory-oriented interface using a hidden file in the current directory
(but which still keeps the "connect to any grassdata/location/mapset"
concept):

{{{
grass init grassdata/location/mapset EPSG:3358
grass lock grassdata/location/mapset
grass exec r.import input=some_image.tif output=some_image
grass exec r.info some_image
grass exec r.mapcalc "improved_image = 5 * some_image"
grass exec r.out.gdal input=improved_image output=improved_image.tif
grass unlock
}}}

(The above is just an idea for now, init and lock could be merged,
grassdata/location/mapset could default to something in init and use more
//convention over configuration// in lock, unlock could be renamed...)

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3967#comment:1&gt;
GRASS GIS <https://grass.osgeo.org>

#3967: Add batch job example without path
--------------------------+------------------------------------
  Reporter: jidanni | Owner: grass-dev@…
      Type: enhancement | Status: new
  Priority: trivial | Milestone:
Component: Docs | Version: unspecified
Resolution: | Keywords: grass.py exec CLI init
       CPU: Unspecified | Platform: Unspecified
--------------------------+------------------------------------

Comment (by jidanni):

OK first let me say that it should be documented that by not including a
PATH the user may think he is actually able to "test in a pristine vanilla
environment" but in fact he is actually just using the previous
environment under the hood... unless he uses --exec...

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3967#comment:2&gt;
GRASS GIS <https://grass.osgeo.org>

#3967: Add batch job example without path
--------------------------+------------------------------------
  Reporter: jidanni | Owner: grass-dev@…
      Type: enhancement | Status: new
  Priority: trivial | Milestone:
Component: Docs | Version: unspecified
Resolution: | Keywords: grass.py exec CLI init
       CPU: Unspecified | Platform: Unspecified
--------------------------+------------------------------------

Comment (by jidanni):

All this is getting too complex for me.
Maybe document a way to use a /dev/null mapset so the user can run some
e.g., g.gisenv or whatever queries if he wants, without worrying that they
access or store to any particular mapset.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3967#comment:3&gt;
GRASS GIS <https://grass.osgeo.org>

#3967: Add batch job example without path
--------------------------+------------------------------------
  Reporter: jidanni | Owner: grass-dev@…
      Type: enhancement | Status: new
  Priority: trivial | Milestone:
Component: Docs | Version: unspecified
Resolution: | Keywords: grass.py exec CLI init
       CPU: Unspecified | Platform: Unspecified
--------------------------+------------------------------------

Comment (by wenzeslaus):

Replying to [comment jidanni]:
> ...user may think he is actually able to "test in a pristine vanilla
environment" ...
> All this is getting too complex for me.

You are actually right. The documentation assumes that you start with
`--exec` etc. after you have some knowledge of GRASS GIS already. That's
wrong assumption and unnecessary requirement. I can see now that it is
actually misleading.

I don't have a clear plan now for improving it, so any suggestions or PRs
are as always welcome.

> Maybe document a way to use a /dev/null mapset so the user can run some
e.g., g.gisenv or whatever queries if he wants, without worrying that they
access or store to any particular mapset.

There is `--tmp-location` (created in a temporary database/directory)
which allows you to run commands without creating any location (and thus
mapset) permanently (again the documentation assumes you know why it is it
useful). One use of specifically `--tmp-location XY` is running modules
such as g.manual or g.extension which don't work with any data. General
use is running scripts and using GRASS GIS as a processing backend.

A temporary mapset (`--tmp-mapset`) would make sense too for same cases
(see [wiki:GSoC/2019#Neweasy-to-useCLIandAPIforGRASSGIS GSoC 2019 New Easy
CLI Idea] for the suggestion).

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3967#comment:4&gt;
GRASS GIS <https://grass.osgeo.org>