[GRASS-dev] Handling of Python scripts on MS Windows

[Glynn Clements]

Markus Metz wrote:

> >> It's easier to check if the file is a python script and if so than
> >> to force to use bundled version of Python.
> >
> > So long as I have commit access, GRASS isn't going to be "forcing" the
> > use of a non-system Python.
> 
> But an existing system Python on MS Windows can change or disappear
> any time, and a GRASS installation will not be notified about this
> change.

Yes; and your point is?

If my system Python were to suddenly change or disappear, I'd be far
more concerned about "who did that, and how?" than about GRASS not
working.

> > By all means provide fall-backs, workarounds, alternatives, or
> > whatever, but anything which tries to make such things mandatory is
> > going to get reverted. Again.
> 
> How about ignoring .py file associations and set GRASS_PYTHON to the
> system's Python? If that does not work or disappeared, make
> GRASS_PYTHON fall back to the embedded version? IOW, always use
> GRASS_PYTHON, but let GRASS_PYTHON be the system's Python if possible.

1. GRASS_PYTHON is just a pathname (it needs to be quoted in the batch
file because it may contain spaces), while the registry entry can
specify switches. This could be worked around by setting GRASS_PYTHON
to a batch file, but ...

2. Batch files just add another source of potential problems. E.g. 
anything beyond the simplest cases fails on non-ASCII data (more
precisely, whenever you use bytes which don't have identical
interpretations in the "ANSI" and "OEM" codepages).

Personally, I'd rather just execute the scripts directly, as is done
on Unix.

> The downside is, GRASS would need a new mechanism to test if python
> scripts can be executed on the current system. This mechanism would
> need to be run before any GRASS modules. We would also need clear
> messages to users about any problems and how these problems can be
> resolved. Further on, any solution should not require administrative
> privileges.
> 
> Anyway, IMHO we really must have a mechanism to avoid the system's .py
> associations because an existing Python file association on MS Windows
> can change or disappear any time, and a GRASS installation will not be
> notified about this change.

ESRI don't appear to be concerned about this "problem", and their
users are paying them (rather heavily, I might add). And they don't
even have to consider portability; it's Windows-only.

We're not even demanding that our users use a specific Python package,
only a relatively recent official Python 2.x release (i.e. something
which actually deserves to "own" the .py association). Or something
which is at least minimally compatible.

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