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

[Glynn Clements]

Markus Metz wrote:

> >> Other projects such as gimp or libreoffice are AFAICT reasonably
> >> bundled with Python, without a Python installer.
> >
> > They aren't attempting to support Python scripts as stand-alone
> > programs (i.e. something which can be run from the command prompt,
> > batch files, etc).
> 
> GRASS scripts, just like GRASS C modules, only run as stand-alone
> programs if the GRASS environment is set properly and if a valid GRASS
> session has been established.

This is a matter of creating a file and setting some environment
variables.

It's also not that specific to GRASS. As the Windows filesystem layout
groups files by origin (i.e. .../Program Files/<vendor>/<package>)
rather than by function (.../bin, .../lib, etc), it's fairly typical
to have to at least modify PATH for anything which is meant to be used
from the command line.

But you can't configure interpreters on a per-process basis on Windows.
You can only do it on Unix because we use the "#!/usr/bin/env python"
hack (which was originally invented to deal with Python being either
in /usr/bin or /usr/local/bin).

> Thus, GRASS modules do not run from any
> command prompt, neither from the native Windows command prompt nor
> from a *NIX shell, without setting the GRASS environment first. Real
> stand-alone programs are for example the GDAL utilities, but not GRASS
> modules.

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.

FWIW, I want to make that the default mode of operation.

I.e. on Unix, set the environment variables in /etc/profile.d/grass7
or whatever a given distribution uses, so that you only need to
explicitly start GRASS sessions if you want multiple, independent
sessions.

On Windows, GISBASE should be set from the registry (with the
environment variables allowing this to be overriden, mainly as a
developer feature).

> > A compiled program which "embeds" Python (links against the Python
> > DSO/DLL) to use Python for "internal" scripting is a much simpler
> > case. And much less useful.
> 
> Why much less useful? As far as GRASS modules are concerned, users
> should not be bothered and should not care if a GRASS module is a C
> module or a shell script or a python script. First of all, a GRASS
> module must behave like a GRASS module, independent of the language in
> which it is written.

This is my entire point. But that cannot be achieved if you're relying
upon hard-coded special treatment for Python scripts. If Python
scripts cannot simply be executed (via system() or subprocess.Popen()
or whatever) in the same manner as executables or other scripts, the
user will have to be bothered with whether something is an executable
or a Python script.

Attempting to side-step the system's execution mechanism will *always*
be an incomplete solution.

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