[GRASS-dev] Re: [GRASS GIS] #580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run

[GRASS GIS]

#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
---------------------------+------------------------------------------------
  Reporter:  hamish        |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect        |      Status:  new                      
  Priority:  blocker       |   Milestone:  6.4.0                    
 Component:  wxGUI         |     Version:  6.4.0 RCs                
Resolution:                |    Keywords:  wingrass                 
  Platform:  MSWindows XP  |         Cpu:  Unspecified              
---------------------------+------------------------------------------------
Comment (by glynn):

 Replying to [comment:6 hamish]:

 > > The normal way to associate applications with extensions is via
 > > assoc and ftype (but AFAICT, those change the system-wide
 > > settings, which may have be overriden by per-user settings).
 > ...
 > > Note that this will change the registry keys, which will
 > > permanently affect the handling of all .py files on the system,
 > > not just those which are part of GRASS, and not just for the
 > > lifetime of the command prompt.
 >
 > ... leading to more like bug #570

 I thought that #570 related specifically to the GUI.

 Note that the GUI is a bit more problematic because it requires a version
 of Python with wx 2.8, and relying upon the system Python having this is a
 bit optimistic (but not entirely unrealistic; wxPython has stock binary
 packages to match the stock Python 2.4, 2.5 and 2.6, and supports
 concurrent installation of multiple versions of wxPython).

 > So lacking a way to locally set the extension association, our only
 choice is to ditch PATHEXT and use wrapper scripts which ensure that the
 GRASS_PYTHON enviro var. is respected.

 The obvious choice is to simply use the system Python, just like we do on
 Unix.

 It's not as if the user is overwhelmed by a choice of 20 different third-
 party Python packages. There are standard Windows (and MacOSX) binary
 packages available from the python.org website (without any of the
 licensing issues associated with relying upon !ActiveState, like was the
 case for Tcl/Tk).

 If the user wants to associate the .py extension with something which
 isn't compatible[*] with the stock Python, that's their problem. It's not
 like we support Unix systems where /bin/sh is csh, either.

 [*] It doesn't have to actually '''be''' the stock Python, but it does
 need to provide the same language with the same modules. Scripts don't
 need binary compatibility.

 > > but any standalone scripts will use the system Python
 > > installation, and GRASS shouldn't be interfering with that
 >
 > is there anything left which won't use the python set by the
 GRASS_PYTHON enviro variable? (from #570 apparently the answer is yes)

 Running a .py script from the command line or via the Windows shell (i.e.
 via !ShellExecute, which includes {{{subprocess.Popen(..., shell =
 True)}}}) won't use GRASS_PYTHON, nor should it. Even within a GRASS
 session, the command line should be able to run non-GRASS commands,
 including those written in Python.

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