[GRASS-dev] [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@…              
      Type:  defect        |      Status:  reopened                 
  Priority:  blocker       |   Milestone:  7.0.0                    
 Component:  wxGUI         |     Version:  svn-trunk                
Resolution:                |    Keywords:  wingrass                 
  Platform:  MSWindows XP  |         Cpu:  Unspecified              
---------------------------+------------------------------------------------

Comment(by glynn):

 Replying to [comment:51 mmetz]:

 > > WinGRASS isn't "compiled" against any version of Python.
 >
 > OK, but GRASS is compiled "with" a particular Python version, for
 ctypes.

 The ctypesgen program which generates the ctypes wrappers is a Python
 script. The generated ctypes wrappers don't depend upon the version of
 which Python was used to run ctypesgen.

 > And apparently wxversion is needed which is only available in a devel
 package (Linux).

 That would be a bug in the particular distribution. The Windows installers
 for wxPython include wxversion, and any sane Linux package for wxPython
 would do likewise. By separating wxversion from the main wxPython package,
 the distribution is effectively insisting that any wxPython-based code is
 customised for that specific distribution (i.e. is written for, and
 doesn't attempt to check for, that distribution's "official" wxPython
 version).

 > Should the existence of a working Python interpreter thus be the
 responsibility of the user? Should we therefore remove the bundled python
 from the wingrass installer? Because we do not want to interfere with an
 existing Python installation, we either do not include an official Python
 installer, or we do, but check first if any Python is already installed on
 the system.

 The latter is preferable, but more work. I.e. if Python is not installed,
 we should attempt to install it (via official installers) and required
 packages. If Python is installed, we should check that it's a compatible
 version, and attempt to install any required packages (wxPython, numpy,
 etc) for that specific version.

 > According to Helmut's report [comment:48] on the registry settings, I
 can not see any trace of the Python versions coming with Inkscape and
 !LibreOffice, but only of the Python version coming with ArcGIS.

 GUI "applications" don't require an installed Python. Typically, the
 Python interpreter is embedded in the application's main executable.
 Python scripts are only ever run from within that application. Often,
 scripts which are part of the application package wouldn't run elsewhere
 because they depend upon modules which are compiled into the application's
 executable.

 This doesn't work when we're trying to provide a command-line and/or
 scripting environment. Ultimately, people should be able to write scripts
 and run them e.g. from an icon on the desktop or from some other program
 which knows nothing about either GRASS or Python.

 (This depends in part upon fixing the installation process to make GRASS
 "sessions" an optional feature. I can't remember the last time I actually
 "started GRASS"; I just set up all of the environment variables in
 ~/.bash_profile so that GRASS commands work everywhere).

 > To phrase it provocatively, do we want to go the ESRI way or do we want
 to go the Inkscape and !LibreOffice way?

 ESRI way.

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