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

[Glynn Clements]

Markus Metz wrote:

> GRASS has to check each time it is started if a compatible system-wide
> .py file association is available. This is IMHO nonsense.

Performing that test would be nonsense.

Any application depends upon certain functionality being provided by
the underlying platform. There are an unlimited number of ways that
you can break the platform such that GRASS stops working. Singling out
one of them in particular as needing to be checked is just silly.

> Anyway, there are four valid Python installations for MS Windows:
> 
> - Python 3 64 bit
> - Python 3 32 bit
> - Python 2 64 bit
> - Python 2 32 bit
> 
> IMHO, we can not wait until all these versions are supported by the
> same GRASS7 wingrass installer.

I don't care about the installer. I do care about the suggestion of
making changes to core GRASS code such that you would actually have to
modify the internals to have Python scripts executed normally (i.e. in
by the same mechanism as for anything that isn't GRASS).

If I write a C program which executes a Python script using
system("/path/to/script.py"), it *is* going to use the interpreter
specified by the registry's file associations. I expect the same
interpreter to be used when that script is executed by something which
is part of GRASS.

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

I mean that you pass the path to the script and its arguments to the
execution function (system() or whatever), and leave the platform to
deal with the rest. You don't try to second-guess or bypass the
platform.

E.g. if .py is associated with the Python launcher, I expect to be
able to control which Python version is used via the launcher's
configuration mechanism, without first having to figure out how all
this is being bypassed then un-bypassing it.

> > We're not even demanding that our users use a specific Python package,
> 
> Yes we do. At the moment we require the same Python 2.x 32 bit version
> that is embedded in OSGEO4W and the standalone WinGRASS installer.
> Remember, we are taking about the status quo.

I'm talking about GRASS, not the installer.

I don't particularly care about the installer, as anyone can simply
provide a sane alternative. But they shouldn't have to patch the code,
which would be required if some of the suggestions (e.g. intercepting
grass.script.Popen()) gained traction.

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