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

Markus Metz markus.metz.giswork at gmail.com
Tue Apr 22 12:18:18 PDT 2014


A short comment about GRASS as a monolithic application or not:
On every OS where I tested various GRASS versions (I tested on various
Linux distros, on various FreeBSD versions, on various NetBSD
versions, on 2 Solaris versions and helped give IBM AIX a try) and on
all these OS's I started GRASS with the grassxy command, usually not
bothering about a GUI but using the command line exclusively. All I
propose is that GRASS on Windows behaves the same, and that all GRASS
commands work, no matter if they are real executables or some scripts.

I hope we can agree on that.

I think this discussion has gone astray. This is about how GRASS
scripts are executed on Windows, not whether GRASS on WIndows should
behave any different than on other OS's.

There seems to be agreement that changing an existing Python file
association 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.
Therefore it is IMHO not a good idea to rely on a system-wide Python
file association on MS Windows, and therefore I propose to use the
embedded Python version already coming for some years with the
WinGRASS installer.

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.

Markus M


More information about the grass-dev mailing list