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

 == find_program ==

 Replying to [comment:31 hamish]:
 > Replying to [comment:29 wenzeslaus]:
 > > It could be convenient (for both the interface and implementation) to
 > > have special function to test presents of GRASS modules.
 >
 > just to note that the last version of that I saw failed to pick up Addon
 modules.
 > (installed in either the GRASS_ADDON_PATH(s) &/or ~/bin/)
 >
 Did you test r56869? To be honest, I never remember if `GRASS_ADDON_PATH`
 is in `PATH`. If it is not in `PATH`, `find_program` (`test/run_program`)
 probably not work for addons. Maybe another reason for creating new
 function for modules. We can even call it `is_module_present/here` to
 create nicely readable code. You can provide your suggestions, especially
 those English-correct. The implementation is clear: same as current
 (glynn's) `find_program` (run the module), `help` parameter added and all
 GRASS acceptable paths used.

 == test in g.manual ==

 Replying to [comment:30 hamish]:
 > Replying to [comment:29 wenzeslaus]:
 > > Anyway, in r56880 I have deleted the test in g.manual since I
 > > don't see any reason for it.
 >
 > In r56882 I have put it back. It is nice to have the clearer error
 message on Linux (where the error could come up a lot), and in cases where
 GRASS_HTML_BROWSER is either unset of malformed. It may need to be
 improved or fixed, but it should be there.
 >

 Tell me examples, please. I don't see much difference between "''Browser
 '%s' not found''" and "''Error starting browser '%(browser)s' for HTML
 file '%(path)s'''".

 Since the test (`find_program`) does not work for clear examples such as
 `firefox`, I don't see the reason to keep the test there to produce just
 slightly better error message in other cases (moreover, the meaning of the
 message is absolutely clear only if you know, which function/test caused
 this message, IMHO).

 Anyway, if you think that the test is necessary, we can use the
 `shutil.which` function to do the test. Thus, we will have two functions,
 as already proposed by annakrat in comment:25.

 == opening HTML page ==

 Replying to [comment:32 glynn]:
 > Replying to [comment:29 wenzeslaus]:
 >
 > > > More generally, there should probably be separate functions for
 "opening" a file or URL in the user's desktop environment.
 > >
 > > Sorry, I don't get your last point. Would you like to have
 `open_something` function in GRASS or do you expect this function to be
 available from system or something else?
 >
 > I think that GRASS should have something. On Windows, this doesn't
 require testing for specific programs; subprocess.call(file, shell=True)
 should suffice.
 >
 > > Diverging from the original ticked topic, the
 `GRASS_HTML_BROWSER=firefox` blocks the command line even after r56880
 when no firefox session is running. However, this is expected and I think
 there is no way how to avoid this when we want (probably because of cmd
 line web browsers) to use `execlp`.
 >
 > GRASS_HTML_BROWSER is probably too simplistic. E.g. a GUI browser should
 be executed in the background, whereas e.g. lynx shouldn't. But something
 like xdg-open should probably be preferred.


 As for the ''opening file topic'', we shall create new ticked. However,
 for now, I have to say that I don't like the idea of re-implementation of
 the `xdg-open`-like functionality in GRASS, especially when primary
 backend will be something like `xdg-open` or standard windows
 functionality. Although I agree that the current state is insufficient.

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