[GRASS-dev] r54612 - grass/trunk/mswindows - wingrass: attempt to define python file association

Glynn Clements glynn at gclements.plus.com
Tue Jan 15 01:11:12 PST 2013


Markus Metz wrote:

> > Hm, not sure. Esri ArcGIS contains also installation of Python.
> 
> Esri ArcGIS installs system-wide a true Windows version of Python.
> Another possibility is to look at the way e.g. LibreOffice or Gimp
> install python on Windows (not system-wide).

AFAIK, those packages only support Python scripting within the
application. That's the easy case.

A system-wide installation means that you can "execute" Python scripts
from a command prompt, from batch files, with system(),
subprocess.Popen(), etc, in the same way that you can execute batch
files (CreateProcess() only works for binary executables, so scripts
can never truly be first-class citizens on Windows).

> I found that problems go away if I install
> http://www.python.org/ftp/python/2.7.3/python-2.7.3.msi
> which is a true Windows system-wide installation.

Right. But this isn't something which GRASS can do unconditionally. 
The user may already have a system-wide Python installation for other
reasons, and blindly replacing it with a different version will break
that.

Also, if the user has a system-wide Python, any packages (e.g. 
wxPython, numpy, etc) have to match that specific version.

In particular, if the user has Python 3.x, they are almost certainly
going to require the Python launcher:

	http://docs.python.org/3/using/windows.html#launcher

For this situation, GRASS can set PY_PYTHON in sthe environment to
force a specific Python interpreter within a GRASS session.

It *might* be feasible to bundle the launcher and, if necessary,
forcibly associate the .py extension with the launcher. This could be
acceptable provided that we can be sure that the existing behaviour is
preserved for non-GRASS Python scripts.

As a last resort, we might need to install Python scripts with a
different extension (e.g. .gpy) to allow them to be associated with a
specific Python interpreter without affecting other packages which use
Python (e.g. ArcGIS).

Note that we will be running into similar issues on Linux as some
distributions start using Python 3.x for "/usr/bin/python". But on
Linux, the fix is much simpler: use "#!/usr/bin/env python" and put a
symlink from $GISBASE/bin/python to any Python 2.x interpreter.

-- 
Glynn Clements <glynn at gclements.plus.com>


More information about the grass-dev mailing list