[GRASS-dev] [GRASS GIS] #3632: Add a function to read parameters from a file to the parser

[GRASS GIS]

#3632: Add a function to read parameters from a file to the parser
-------------------------+-------------------------------------------------
  Reporter:  wenzeslaus  |      Owner:  grass-dev@…
      Type:              |     Status:  new
  enhancement            |
  Priority:  normal      |  Milestone:  8.0.0
 Component:  Parser      |    Version:  unspecified
Resolution:              |   Keywords:  g.parser options parameters file
       CPU:              |  long CLI
  Unspecified            |   Platform:  Unspecified
-------------------------+-------------------------------------------------

Comment (by wenzeslaus):

 Replying to [comment:2 mmetz]:
 >
 > Using the example
 > {{{
 > r.slope.aspect elevation=dtm slope=dtm_slope aspect=dtm_aspect -n
 > }}}
 > what is the advantage of the proposed approach over a file that contains
 exactly this line and executing this file? This is already working and
 handled by the OS.

 I'm thinking about these three points:

 1) There is no command line length limitation as the line or lines are
 processed directly by the parser.

 When I have a long r.series input:

 {{{
 > r.series in=map1900,map1901,...,map2100 out=slope meth=slope
 }}}

 I need to switch to `file` instead of `input`.


 {{{
 > cat input.txt
 map1900
 map1901
 ...
 map2100
 > r.series file=input.txt out=slope meth=slope
 }}}

 That of course assumes that `file` was implemented. In case of having the
 parameter file, I need to switch to that while still using `input`.

 {{{
 > cat params.txt
 in=map1900,map1901,...,map2100
 out=slope
 meth=slope
 > r.series --parameter-file=params.txt
 }}}


 2) The scripting is replaced with configuration. This "command line
 scripting" is OS-depended. You want a short line, but backslashes won't
 work in GUI Console (and on MS Win?). Escaping is done in different ways.
 In other words, the format is actually not well defined, so unless you
 already know "command line scripting" on your OS, this will be cumbersome.
 Another syntax related thing are comments which again could have a clearly
 defined syntax (`#` in Bash versus `REM` in CMD).

 So the following ways of storing the parameters as a command with
 indentation and backslash which will work well in unix-like command line
 but not necessarily elsewhere (which is something we need to explain to
 the user),

 {{{
 r.series input=map2001,map2002,dummy,dummy,map2005,map2006,dummy,map2008 \
          output=res_slope,res_offset,res_coeff
 method=slope,offset,detcoeff
 }}}

 would become, e.g., the following YAML file:

 {{{
 input:
   - map2001
   - map2002
   - dummy
   - dummy
   - map2005
   - map2006
   - dummy
   - map2008
 output:
   - res_slope
   - res_offset
   - res_coeff
 method:
   - slope
   - offset
   - detcoeff
 }}}

 Here the advantage is for modules which are implementing some
 model/simulation which usually have a lot of parameters, e.g.
 G7:r.sim.water (which has over 20 parameters) or G7:r.topmodel (which
 actually requires a "parameters file").

 3) This untangles the module from its parameters (splits the "command"
 into module name and parameters). This brings additional questions such
 as: Should we extend the format by adding module name or multiple modules
 and than read that using the `grass` command creating effectively a new
 API (similarly to e.g. PDAL JSON pipelines)? However, what I'm thinking
 about now is the advantage of storing the parameters separately from the
 command itself and than reusing them repetitively (in an interactive
 command line or a script) while being able to override or complete the
 parameters when needed. You can do the same with enough of Python, but
 this would be native.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/3632#comment:3>
GRASS GIS <https://grass.osgeo.org>