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

[Glynn Clements]

Markus Metz wrote:

> This is the fundamental difference and the reason why using a
> system-wide Python can only cause trouble on Windows. On Windows, a
> software package typically includes everything it needs to run,

On Windows, a software package is typically a monolithic executable
with no ability to be controlled by other programs (including the
command interpreter).

> > It's fairly trivial to set a valid GRASS environment globally, so that
> > commands are usable in any shell. That's how I've had it on Linux
> > since roughly forever; I don't run the grass70 script unless I'm
> > testing it.
> 
> At the very least, GRASS needs to clean up temporary files on exit.

Temporary files need to be cleaned up periodically. The term "on exit"
doesn't make sense for something which doesn't start or stop.

> We use hard-coded special treatment for shell scripts and still they
> behave like a GRASS module.

Where?

> I don't see how users are bothered whether
> a module is an executable or a shell script. Internally, GRASS can
> always use system() or subprocess.Popen() for executables and .bat
> files, but not for shell or Python scripts, Therefore we need
> hard-coded special treatment for shell and Python scripts in order to
> make sure that the correct interpreter is used.

IIRC, .bat files were used because there were issues with associating
.sh with MSys' shell (one of them being that MSys itself doesn't do
that, so we'd effectively be forced to make global changes to
something which doesn't "belong" to GRASS).

> > Attempting to side-step the system's execution mechanism will *always*
> > be an incomplete solution.
> 
> I disagree because there is no default system execution mechanism for
> Python scripts: Python is not part of the Windows OS.
> The recommended Python version as of today would be Python 3.3 64 bit.

It's not necessarily "part of" all Linux distributions either, and
some will move to 3.x by default quite soon.

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