[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):

 Replying to [comment:13 glynn]:
 > Replying to [comment:9 wenzeslaus]:
 >
 > > That's true but I don't know how to solve the following case.
 > >
 > > I'm currently testing the testing framework.
 >
 > Your testing framework probably shouldn't be using functions designed
 for normal scripts. Conversely (and more importantly), features which are
 necessary or useful for a testing framework shouldn't be imposed upon
 normal scripts.
 >
 > Write your own "run_command" function atop grass.script.start_command(),
 and use that.
 >
 This is what I wanted to avoid, writing some other wrappers around
 `start_command()` again and again. But now I think that at least this
 time, for now, it it the best option. So, here they are
 source:sandbox/wenzeslaus/gunittest/gmodules.py?rev=60979

 The most interesting function is `call_module` (which might replace some
 of the other functions):

 {{{
 #!python
 def call_module(module, stdin=None, merge_stderr=False, **kwargs):
     if stdin:
         kwargs['stdin'] = subprocess.PIPE  # to be able to send data to
 stdin
     elif 'input' in kwargs and kwargs['input'] != '-':
         raise ValueError(_("stdin must be set when input='-'"))
     if 'stdout' in kwargs:
         raise ValueError(_("stdout argument not allowed, it would be
 overridden"))
     if 'stderr' in kwargs:
         raise ValueError(_("stderr argument not allowed, it would be
 overridden"))

     kwargs['stdout'] = subprocess.PIPE
     if merge_stderr:
         kwargs['stderr'] = subprocess.STDOUT
     else:
         kwargs['stderr'] = subprocess.PIPE
     process = start_command(module, **kwargs)
     # input=None means no stdin (our default)
     # for stderr=STDOUT errors in None which is fine for CalledModuleError
     output, errors = process.communicate(input=stdin)
     returncode = process.poll()
     if returncode:
         raise CalledModuleError(returncode, module, kwargs, errors)
     return output
 }}}

 I should probably add to the documentation that you should not use it for
 huge I/O. If stdin is used it feeds the process with it (I should add a
 check if it is a string). It always returns stdout. By default it captures
 stderr (to be used in a exception) and with merge_stderr=True it redirects
 stderr to stdout.

 I made an experiment and used the word "module" rather than "command".

 About your comment:14, it makes sense. I can try to implement it some time
 later. But we probably cannot apply this to 7 since the change might be
 too invasive as I realized. But it would be good to ensure right usages in
 the future of 7, so I don't know what to do.

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