[GRASS-dev] [GRASS GIS] #2326: Command functions in grass.script.core miss a correct error reporting

[GRASS GIS]

#2326: Command functions in grass.script.core miss a correct error reporting
--------------------------------+-------------------------------------------
 Reporter:  wenzeslaus          |       Owner:  grass-dev@…              
     Type:  enhancement         |      Status:  new                      
 Priority:  major               |   Milestone:  7.1.0                    
Component:  Python              |     Version:  svn-trunk                
 Keywords:  script, exceptions  |    Platform:  All                      
      Cpu:  Unspecified         |  
--------------------------------+-------------------------------------------

Comment(by wenzeslaus):

 What do you (all) think about moving the function `call_module()` from
 testing framework into the `grass.script.core` module?

 The main point of this function is that it raises exception when return
 code of the module is non-zero. Additionally, it provides an convenient
 interface for capturing stdout and stderr and also for (optional)
 providing stdin (as string, or stream). It uses the safest possible way to
 achieve this which is `Popen.communicate()` method.

 By default it captures stdout (stdout=PIPE) and returns it as string and
 captures stderr (stderr=PIPE) and puts it into the exception when return
 code was non-zero. This can be disabled or stderr can be merged to stdout
 (stderr=STDOUT).

  * source:sandbox/wenzeslaus/gunittest/gmodules.py?rev=61134#L84

 The function is universal and it can be used to implement the other
 alternatives (`run_`, `write_`, and `read_`).

 We can change the name to `call_command()` to be consistent with other
 functions or we can use `call_module()` to emphasize that it have
 different interface.

 It raises exception derived from `subprocess`'s `CalledCommandError`. But
 there is not special need for that. This is just for consistency with
 `subprocess`'s `check_call` function which is not used by `call_command`
 or in GRASS.

  * source:sandbox/wenzeslaus/gunittest/gmodules.py?rev=61134#L

 It has tests to prove that it behaves how it should.

  *
 source:sandbox/wenzeslaus/gunittest/testsuite/test_gmodules.py?rev=61134#L26

 This of course does not solve the problems of wrong usage of `run_command`
 and it does not enforce usage of fatal error. However, it allows to write
 new code for libraries and scripts in a better, Python-friendly, way. The
 usage for this function is where the module is used more like a function
 then as a subprocess, in this case we don't care much about module
 progress or messages unless there was an error. Typical usage are the
 modules providing some stdout with key-value pairs.

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2326#comment:18>
GRASS GIS <http://grass.osgeo.org>