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

[Markus Metz]

On Tue, Feb 4, 2014 at 11:29 AM, Glynn Clements
<glynn at gclements.plus.com> 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. 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.
>
> 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.
>
>> > Most of the troubles arise from attempting to use a mixture of a
>> > bundled version and a system-wide installation.
>>
>> I agree. It seems that the wxGUI always uses the bundled GRASS_PYTHON,
>> the reason why the wxGUI works fine without a system-wide Python.
>
> That was done so that the system Python doesn't need to have wxPython
> installed. Note that wxpyimgview does something similar: the top-level
> script invokes the wxPython program via GRASS_PYTHON explicitly.

Not a good idea, as long as the embedded Python is not always used
explicitely. This mixes the embedded Python with any existing system
Python which in turn causes the infamous MAXREPEAT error.

>>
>> Other projects do bundle Python, and there it seems to work just fine.
>
> They don't merely bundle it, they embed it, which is a much simpler
> case. The downside is that Python can only be used within a monolithic
> GUI application, which isn't how GRASS works.

I disagree. On GRASS 6, the shell interpreter is embedded, and GRASS
can be used in a perfectly modular way, e.g. by the Sextante plugin.
Wrapping Python scripts in .bat files, just like shell scripts are
wrapped in .bat files for GRASS 6, preserves the modular operation of
GRASS.

>
>> I don't understand why we can not also bundle Python, including all
>> required Python packages.

I meant embed, not bundle.

>>
>> Otherwise, users would need to install Python, wxPython, numpy, scipy,
>> matplotlib, datetime themselves (not sure if the list is correct and
>> complete).
>
> We can facilitate this in most cases. If there isn't already a Python
> installation, we can just install the latest 2.x version from the MSI,
> and all required packages. If there is a suitable Python installation,
> we can leave that and just install any required packages.

But after the next upgrade of the system Python, GRASS might no longer
be working, and the user is confused.
>
> The problem only arises when there is an existing installation which
> is unsuitable (incompatible version of Python or additional packages).
> In that situation, either the user has to make a choice or we need to
> figure out how to use the launcher.

We should use the embedded Python explicitly to avoid this problem. We
were here already. From a user's perspective, the easiest would be if
GRASS ignores any system-wide Python installation.

Markus M