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

[Markus Metz]

Glynn Clements wrote:
>
> 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.

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,
embedding any script interpreters, while Linux, Unix, BSD systems use
package managers. The fact that ArcGIS installs a system-wide Python
is maybe a curiosity coming from the origins of ArcInfo as a Unix
application.

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

At the very least, GRASS needs to clean up temporary files on exit.
>
> 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.

I have multiple, independent sessions running pretty much every day.
>
>> > 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.

We use hard-coded special treatment for shell scripts and still they
behave like a GRASS module. 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.

IMHO, the argument to have GRASS as a GIS processing engine in the
background (e.g. for Sextante) that includes everything it needs and
does not interfere with other software packages is a pretty strong
argument.
>
> 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.

Markus M