[GRASS-dev] [GRASS GIS] #2008: grass.script's find_program() can't find modules

[GRASS GIS]

#2008: grass.script's find_program() can't find modules
-----------------------+----------------------------------------------------
  Reporter:  hamish    |       Owner:  grass-dev@…              
      Type:  defect    |      Status:  reopened                 
  Priority:  critical  |   Milestone:  6.4.4                    
 Component:  Python    |     Version:  svn-releasebranch64      
Resolution:            |    Keywords:  find_program()           
  Platform:  All       |         Cpu:  x86-64                   
-----------------------+----------------------------------------------------

Comment(by glynn):

 Replying to [comment:14 zarch]:

 > But why not use the one developed by the python developers?

 Because it's an order of magnitude more complex than it needs to be, and
 less robust as a consequence. Also, it doesn't test whether the program
 actually works. An installed executable with missing shared libraries, an
 installed executable for the wrong architecture, or an installed script
 with a missing interpreter would all pass the new test. For a locked-down
 SELinux system, the correlation between whether the test passes and
 whether the program works could be quite close to zero.

 The Python community often advocates the use of EAFP ("Easier to Ask for
 Forgiveness than Permission", i.e. try it and see if it works) in
 preference to LBYL ("Look Before You Leap", i.e. do lots of tests to try
 to predict whether something will work).

 That principle doesn't appear to have been followed with shutil.which().
 But then shutil.which() is trying to mimic the Unix "which" command, which
 isn't actually a test, it's a query for the filename corresponding to a
 command. What we want is a test.

 > If the meaning of this function is just a python replacement for the
 equivalent "which" bash command.

 Not entirely. We want to know if a particular program is present and
 functional on the system. We don't care where it is, but we do care
 whether it works (which the replacement doesn't test).

 > Moreover asking only for the program is less prone to errors, that can
 be introduce by change of the command interface, and this is especially
 true if we use this function for library developed by others communities.

 In order to test that the program works, and to perform the test with
 minimal side-effects, it's sometimes necessary to pass an argument (e.g.
 --help or --version). Running the program with no arguments may do too
 much (e.g. fire up a GUI).

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