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

[Moritz Lennert]

On 28/01/14 12:07, Markus Metz wrote:
> On Mon, Jan 27, 2014 at 12:16 AM, Glynn Clements
>> "Executing" a script uses the registry associations for the script's
>> extension.
>
> WinGRASS does not set registry associations for Python scripts, nor
> does it install Python system-wide. This is because we do not want to
> modify an existing Python installation.

And that is what is currently causing the issues AFAIU: when calling a 
.py script (or at least when a .py script is called from a .py script) 
the system-wide installation is called and if that is not compatible, we 
have an issue. But as mentioned elsewhere in this thread, it is even 
more complicated because in certain situations is the the GRASS Python 
interpreter which is called, but some of the libraries used are those of 
the system-wide installation.

Out of the current discussion I see the following options:

- Leave correct system-wide installation to the user and not to the 
GRASS-dev team. This could include some help in form of installation 
check and proposal for installation during WinGRASS install and adequate 
doc.

- Try to make sure that any call to any Python script in GRASS is done 
via the GRASS Python interpreter (through .bat scripts, with adquate 
GRASS_PYTHON settings, etc). I'm not sure how we can ensure that none of 
the system-wide libraries are called in this case (e.g. MAXREPEAT issue).

- Creating a virtualenv when installing/launching GRASS and executing 
all Python calls within this virtualenv. AFAIU, this means that those 
who want to combine other Python tools with GRASS either have to install 
them all in that virtualenv.

- Maybe use the Python launcher, set a specific Python version through 
the launcher and explicitely call that version in GRASS. Again, I don't 
know how well this works with other Python installations (in my small 
experiment I had trouble mixing Python 2 and 3 [1].


In summary, again within the limits of my understanding, it seems that 
the choices are between

1) how much burden we put on the user or not
2) how much we want to encapsulate GRASS into an isolated Python 
environment, possibly making interaction with other Python tools on the 
system more difficult.

All obviously with the additional question of how much dev power we 
can/want to put into this issue.

I also have to say that I prefer that we take the time to find a good 
solution, despite all the frustration this is creating.

Moritz

[1] http://lists.osgeo.org/pipermail/grass-dev/2013-July/065197.html