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

[Glynn Clements]

Markus Metz wrote:

> There seems to be agreement that changing an existing Python file
> association is not a good idea.

The problem is that every possible solution has some aspect which is
"not a good idea".

> 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.

Note that the same is also true of the .bat file association. On Unix,
"python" may change from 2.x to 3.x.

There is a limit to how far we can (or should) go to protect against
defects in the underlying platform. Every workaround has an associated
cost.

> Therefore it is IMHO not a good idea to rely on a system-wide Python
> file association on MS Windows,

Regardless of whether or not it's a good idea, it's not entirely
avoidable.

If a process "executes" a command using the system's interfaces
(system(), CreateProcess(), subprocess.Popen(), batch files, etc), and
that command refers to a Python script, the registry's .py file
association *will* be used.

> and therefore I propose to use the
> embedded Python version already coming for some years with the
> WinGRASS installer.

You can only force the use of a specific Python interpreter when
you control the execution mechanism. Otherwise, the system's file
associations will be used.

Users who aren't willing to live within whatever walled garden you
provide will have to have a valid system-wide Python installation. In
that situation, that installation should be used always, not just for
those cases where you can't interpose your workaround.

> With .bat file wrappers, you would not even need to set a particular
> python environment, it would just work. Just as on any other OS, all
> GRASS commands would be available after running the grassxy command.
> If, as Glynn suggests, running grassxy should not be required, instead
> the GRASS environment is set permanently at login time, there would be
> no difference, except that you don't need to bother about funny
> (non-)existing Python file associations on MS Windows.
> 
> I suspect the whole discussion boils down to the question whether we
> can rely on GRASS-compatible Python file associations on MS Windows or
> not. I say, we can not.

For me, the discussion boils down to:

1. How invasive is this workaround going to be with regard to the rest
of GRASS?

2. How easy is it to disable this workaround and just use the system
Python instead?.

IMHO, "solutions" such as making run_command() detect Python scripts
and apply special treatment are non-starters on both fronts.

Batch files are a better solution, as they don't affect anything else,
and it's a simple matter to either delete them or modify PATH to
ignore them, and use the Python scripts directly.

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