[GRASS-dev] Re: [GRASS GIS] #841: python script modules should use pythonw on OSX; they also ignore GRASS_PYTHON

[GRASS GIS]

#841: python script modules should use pythonw on OSX; they also ignore
GRASS_PYTHON
--------------------------+-------------------------------------------------
  Reporter:  kyngchaos    |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect       |      Status:  new                      
  Priority:  normal       |   Milestone:  6.5.0                    
 Component:  default      |     Version:  unspecified              
Resolution:               |    Keywords:                           
  Platform:  Unspecified  |         Cpu:  Unspecified              
--------------------------+-------------------------------------------------
Comment (by glynn):

 Replying to [comment:2 kyngchaos]:

 > > Most 7.x scripts don't use wxPython directly. They might use it
 indirectly via g.parser, but that should be dealt with by $GRASS_PYTHON.
 >
 > OK.  I was going by the new v.krige in 6.5, where I noticed the problem.
 So, the g.parser stuff happens in a completely separate process?

 Yes.

 > What I saw in one module I looked at is that the script loads the grass
 module, then runs grass.parser(), then runs the main script.  No chance
 for it to run anything with GRASS_PYTHON.

 grass.parser() runs g.parser, which calls G_parser(); if arguments are
 required but not provided (or if the --ui switch is given), this will run
 menuform.py via $GRASS_PYTHON (module_gui_wx() in lib/gis/parser.c).
 Eventually, g.parser will return the option/flag values back to the
 script, which doesn't care whether g.parser got the values from the
 command line or from a GUI dialog.

 > > AFAICT, most scripts should be using "python", not "pythonw"
 >
 > Except when they use wx, like v.krige.

 Most scripts shouldn't be using wx. In fact, we may want a completely
 separate directory for this. IMHO, anything in the scripts directory
 should behave like a normal GRASS module (parse command line, perform
 processing, terminate). Applications are something else, even if they're
 written in Python.

 > >> Though, I see another potential problem with the #! -- it completely
 ignores GRASS_PYTHON,
 > > That shouldn't be a problem.
 >
 > How is that not a problem?  Say there are 2 pythons in the PATH (or
 another not in the PATH) and I don't want to use the first one, so I set
 GRASS_PYTHON to the full path to the other.  But then /usr/bin/env
 python[w] goes and runs the first one anyways.

 That's already the case for every other Python script on your system (and
 similarly for /bin/sh etc). GRASS_PYTHON exists as a workaround for the
 case where the system Python cannot be used. AFAICT, the primary use case
 is where binary GRASS packages bundle a version of Python because that's
 the only way that we can ensure compatibility with extensions such as
 vdigit and nviz.

 In any case, you can't use environment variables within the #! line (which
 is ignored on Windows anyhow). No other project seems to consider this a
 problem (not just for Python, but for any interpreted language).

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