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

GRASS GIS GRASS GIS developer
21

Moritz Lennert wrote:

Another option would be to do what Glynn has been proposing all along
(IIUC), which is to not install Python with Wingrass, but rather leave
it up to the user to make sure a suitable Python is installed in the
path.

Actually, my preference would be to first check whether a suitable
Python installation already exists. If it doesn't, offer the user the
option of installing it (by "inatall", I mean download and execute the
appropriate MSI from python.org).

That also means that additional packages (wxPython, NumPy) have to be
installed for the user's Python version, not some fixed version.

Where it gets problematic is if the user already has a Python
installation but it's not suitable for whatever reason. In the worst
case they may be faced with a choice between using GRASS or using
whatever the existing Python was installed for.

The same issue potentially exists on Unix, but it's easier to work
around due to the "#!/usr/bin/env python" hack, as we can just put a
"python" symlink in $GISBASE/bin. In effect, we're using "env" as a
Python launcher on Unix.

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

22

On 21/01/14 16:34, Glynn Clements wrote:

Moritz Lennert wrote:

Another option would be to do what Glynn has been proposing all along
(IIUC), which is to not install Python with Wingrass, but rather leave
it up to the user to make sure a suitable Python is installed in the
path.

Actually, my preference would be to first check whether a suitable
Python installation already exists. If it doesn't, offer the user the
option of installing it (by "inatall", I mean download and execute the
appropriate MSI from python.org).

That also means that additional packages (wxPython, NumPy) have to be
installed for the user's Python version, not some fixed version.

I have no idea what this means in terms of complexity of the installer, but I do imagine that this implies different approaches for the standalone installer and the osgeo4w installer, or ?

Moritz

23

Moritz Lennert wrote

On 21/01/14 16:34, Glynn Clements wrote:

Moritz Lennert wrote:

Another option would be to do what Glynn has been proposing all along
(IIUC), which is to not install Python with Wingrass, but rather leave
it up to the user to make sure a suitable Python is installed in the
path.

Actually, my preference would be to first check whether a suitable
Python installation already exists. If it doesn't, offer the user the
option of installing it (by "inatall", I mean download and execute the
appropriate MSI from python.org).

That also means that additional packages (wxPython, NumPy) have to be
installed for the user's Python version, not some fixed version.

I have no idea what this means in terms of complexity of the installer,
but I do imagine that this implies different approaches for the
standalone installer and the osgeo4w installer, or ?

regarding complexity of the standalone installer, it would be doable at
least with some effort;
regarding osgeo4w it has to be tested.

Glynn Clements:

Where it gets problematic is if the user already has a Python
installation but it's not suitable for whatever reason. In the worst
case they may be faced with a choice between using GRASS or using
whatever the existing Python was installed for.

IMHO keeping in mind that many GIS-interested winGRASS-users may already
have been installed other (GIS-)software including a system-wide python
installation, that will be the demanding challenge to provide a suitable
solution ...

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Handling-of-Python-scripts-on-MS-Windows-tp5081335p5099340.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

24

Helmut Kudrnovsky wrote:

Moritz Lennert wrote

Glynn Clements:

Where it gets problematic is if the user already has a Python
installation but it's not suitable for whatever reason. In the worst
case they may be faced with a choice between using GRASS or using
whatever the existing Python was installed for.

IMHO keeping in mind that many GIS-interested winGRASS-users may already
have been installed other (GIS-)software including a system-wide python
installation, that will be the demanding challenge to provide a suitable
solution ...

Therefore I would suggest to keep using the embedded Python version
which is known to work and includes all required components. Wingrass
would need *.bat wrapper scripts as for GRASS6 in order to make sure
that GRASS7 Python scripts are called with GRASS_PYTHON.

One reason for using Python is that many users are familiar with
Python and can easily write their own scripts. Writing Python scripts
is made easier if a Wingrass user associates Python scripts not with
Python but with the text editor of choice, in which case the system
handler will not execute Python scripts, but edit them. Now the task
is to not only make writing Python scripts easy, but also executing
them. This is done via File -> Launch script. There is no reason to
assume that any system-wide .py association is suitable to execute
GRASS Python scripts, thus the easiest way out might be to just ignore
it.

my 2c

Markus M

25

Markus Metz wrote:

>>Where it gets problematic is if the user already has a Python
>>installation but it's not suitable for whatever reason. In the worst
>>case they may be faced with a choice between using GRASS or using
>>whatever the existing Python was installed for.
>
> IMHO keeping in mind that many GIS-interested winGRASS-users may already
> have been installed other (GIS-)software including a system-wide python
> installation, that will be the demanding challenge to provide a suitable
> solution ...

How many users will have versions which are:

a) too old for GRASS to use, and
b) required to be that old by the existing package?

Bear in mind that GRASS won't be the only package affected by an
outdated system-wide Python installation.

AFAIK, the primary case where another package requires a system-wide
Python installation is ArcGIS, no? IIRC, ArcGIS requires Python 2.6;
is there some fundamental reason why this isn't suitable for GRASS? If
so, does ArcGIS require that exact version, or can it use a later
version?

Therefore I would suggest to keep using the embedded Python version
which is known to work

Actually, it known not to work, hence this thread.

The only way you can make execution of Python scripts seamless (i.e.
works with system(), subprocess.Popen(), etc) is for the .py extension
to be associated with a suitable interpreter (or launcher) in the
registry.

Any other approach will trap us into an endless maintenance burden,
identifying cases where we have to provide special handling for Python
scripts then implementing that handling.

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

26

On Fri, Jan 24, 2014 at 9:03 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Markus Metz wrote:

>>Where it gets problematic is if the user already has a Python
>>installation but it's not suitable for whatever reason.

Could we write a small test script which is executed by the installer
to actually test the suitability (to then decide if that system-wide
Python can be used or the embedded one)?

Which Python functions do we need to look for?

Markus

27

Just a note, given that most of these problems were caused by conflicts with python installed by ArcGIS,
I checked with our GIS support and the latest ArcGIS 10.2 installs python2.7 which (I guess) should work with GRASS.

On Jan 24, 2014, at 3:03 PM, Glynn Clements wrote:

Markus Metz wrote:

Where it gets problematic is if the user already has a Python
installation but it's not suitable for whatever reason. In the worst
case they may be faced with a choice between using GRASS or using
whatever the existing Python was installed for.

IMHO keeping in mind that many GIS-interested winGRASS-users may already
have been installed other (GIS-)software including a system-wide python
installation, that will be the demanding challenge to provide a suitable
solution ...

How many users will have versions which are:

a) too old for GRASS to use, and
b) required to be that old by the existing package?

Bear in mind that GRASS won't be the only package affected by an
outdated system-wide Python installation.

AFAIK, the primary case where another package requires a system-wide
Python installation is ArcGIS, no? IIRC, ArcGIS requires Python 2.6;
is there some fundamental reason why this isn't suitable for GRASS? If
so, does ArcGIS require that exact version, or can it use a later
version?

yes, given that most of these problems were caused by conflicts with python installed by ArcGIS,
I checked with our GIS support and the latest ArcGIS 10.2 installs python2.7 which should work with GRASS
(correct me if I am wrong).
We had similar situation with ArcGIS9* and GRASS6.3 where you had to use a specific winpython2.5 build 212
to have both of them working on the same machine.
The test suggested by Markus in the related message would be still useful,
but upgrading to ArcGIS10.2 should solve the problem?

Helena

Therefore I would suggest to keep using the embedded Python version
which is known to work

Actually, it known not to work, hence this thread.

The only way you can make execution of Python scripts seamless (i.e.
works with system(), subprocess.Popen(), etc) is for the .py extension
to be associated with a suitable interpreter (or launcher) in the
registry.

Any other approach will trap us into an endless maintenance burden,
identifying cases where we have to provide special handling for Python
scripts then implementing that handling.

--
Glynn Clements <glynn@gclements.plus.com>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

28

On Sat, Jan 25, 2014 at 3:59 PM, Helena Mitasova <hmitaso@ncsu.edu> wrote:

Just a note, given that most of these problems were caused by conflicts with python installed by ArcGIS,
I checked with our GIS support and the latest ArcGIS 10.2 installs python2.7 which (I guess) should work with GRASS.

No, there are different versions of Python 2.7, and not all work with
GRASS, see e.g. ticket 2015

On Jan 24, 2014, at 3:03 PM, Glynn Clements wrote:

Markus Metz wrote:

Where it gets problematic is if the user already has a Python
installation but it's not suitable for whatever reason. In the worst
case they may be faced with a choice between using GRASS or using
whatever the existing Python was installed for.

IMHO keeping in mind that many GIS-interested winGRASS-users may already
have been installed other (GIS-)software including a system-wide python
installation, that will be the demanding challenge to provide a suitable
solution ...

How many users will have versions which are:

a) too old for GRASS to use, and
b) required to be that old by the existing package?

Bear in mind that GRASS won't be the only package affected by an
outdated system-wide Python installation.

GRASS should not use a system-wide Python installation, or more
precisely, should explicitly ignore any system-wide python file
associations. Expecting system-wide python file associations is the
cause of all the trouble.

The embedded but not installed Python version coming GRASS works fine
and should IMHO be used for scripts via

@"%GRASS_PYTHON%" "%GISBASE%/scripts/SCRIPT_NAME" %*

AFAIK, the primary case where another package requires a system-wide
Python installation is ArcGIS, no? IIRC, ArcGIS requires Python 2.6;
is there some fundamental reason why this isn't suitable for GRASS? If
so, does ArcGIS require that exact version, or can it use a later
version?

We can not care for all cases of other software (versions) relying on
a system-wide python installation.

yes, given that most of these problems were caused by conflicts with python installed by ArcGIS,
I checked with our GIS support and the latest ArcGIS 10.2 installs python2.7 which should work with GRASS
(correct me if I am wrong).
We had similar situation with ArcGIS9* and GRASS6.3 where you had to use a specific winpython2.5 build 212
to have both of them working on the same machine.
The test suggested by Markus in the related message would be still useful,
but upgrading to ArcGIS10.2 should solve the problem?

You can hardly suggest users to upgrade ArcGIS if they want to use GRASS...

Therefore I would suggest to keep using the embedded Python version
which is known to work

Actually, it known not to work, hence this thread.

It works as long as system-wide python file associations are ignored.
Other Python versions might not work.

The only way you can make execution of Python scripts seamless (i.e.
works with system(), subprocess.Popen(), etc) is for the .py extension
to be associated with a suitable interpreter (or launcher) in the
registry.

I disagree. For example, shell scripts work just fine in GRASS 6.4,
even though there is no associated suitable interpreter (or launcher)
in the registry.

Any other approach will trap us into an endless maintenance burden,
identifying cases where we have to provide special handling for Python
scripts then implementing that handling.

We did so for shell scripts, AFAIK this works.

Markus M

29

On 25/01/14 16:48, Markus Metz wrote:

On Sat, Jan 25, 2014 at 3:59 PM, Helena Mitasova <hmitaso@ncsu.edu> wrote:

Just a note, given that most of these problems were caused by conflicts with python installed by ArcGIS,
I checked with our GIS support and the latest ArcGIS 10.2 installs python2.7 which (I guess) should work with GRASS.

No, there are different versions of Python 2.7, and not all work with
GRASS, see e.g. ticket 2015

On Jan 24, 2014, at 3:03 PM, Glynn Clements wrote:

Markus Metz wrote:

Where it gets problematic is if the user already has a Python
installation but it's not suitable for whatever reason. In the worst
case they may be faced with a choice between using GRASS or using
whatever the existing Python was installed for.

There is a tool called "Virtualenv" that seems to address exactly
this problem: https://pypi.python.org/pypi/virtualenv

See also here: http://docs.python-guide.org/en/latest/starting/install/win/

I found it via this thread:
http://stackoverflow.com/questions/1108974/switch-versions-of-python

IMHO keeping in mind that many GIS-interested winGRASS-users may already
have been installed other (GIS-)software including a system-wide python
installation, that will be the demanding challenge to provide a suitable
solution ...

I don't know in how far a pre-existing system installation of
Python would interfere with Virtualenv or similar solutions.

But I hope that the above could be a useful approach to
solving this problem.

Best,

Ben

How many users will have versions which are:

a) too old for GRASS to use, and
b) required to be that old by the existing package?

Bear in mind that GRASS won't be the only package affected by an
outdated system-wide Python installation.

GRASS should not use a system-wide Python installation, or more
precisely, should explicitly ignore any system-wide python file
associations. Expecting system-wide python file associations is the
cause of all the trouble.

The embedded but not installed Python version coming GRASS works fine
and should IMHO be used for scripts via

@"%GRASS_PYTHON%" "%GISBASE%/scripts/SCRIPT_NAME" %*

AFAIK, the primary case where another package requires a system-wide
Python installation is ArcGIS, no? IIRC, ArcGIS requires Python 2.6;
is there some fundamental reason why this isn't suitable for GRASS? If
so, does ArcGIS require that exact version, or can it use a later
version?

We can not care for all cases of other software (versions) relying on
a system-wide python installation.

yes, given that most of these problems were caused by conflicts with python installed by ArcGIS,
I checked with our GIS support and the latest ArcGIS 10.2 installs python2.7 which should work with GRASS
(correct me if I am wrong).
We had similar situation with ArcGIS9* and GRASS6.3 where you had to use a specific winpython2.5 build 212
to have both of them working on the same machine.
The test suggested by Markus in the related message would be still useful,
but upgrading to ArcGIS10.2 should solve the problem?

You can hardly suggest users to upgrade ArcGIS if they want to use GRASS...

Therefore I would suggest to keep using the embedded Python version
which is known to work

Actually, it known not to work, hence this thread.

It works as long as system-wide python file associations are ignored.
Other Python versions might not work.

The only way you can make execution of Python scripts seamless (i.e.
works with system(), subprocess.Popen(), etc) is for the .py extension
to be associated with a suitable interpreter (or launcher) in the
registry.

I disagree. For example, shell scripts work just fine in GRASS 6.4,
even though there is no associated suitable interpreter (or launcher)
in the registry.

Any other approach will trap us into an endless maintenance burden,
identifying cases where we have to provide special handling for Python
scripts then implementing that handling.

We did so for shell scripts, AFAIK this works.

Markus M
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer

  benducke@fastmail.fm

30

Markus Metz wrote:

On Sat, Jan 25, 2014 at 3:59 PM, Helena Mitasova <hmitaso@ncsu.edu> wrote:
> Just a note, given that most of these problems were caused by conflicts with python installed by ArcGIS,
> I checked with our GIS support and the latest ArcGIS 10.2 installs python2.7 which (I guess) should work with GRASS.

No, there are different versions of Python 2.7, and not all work with
GRASS, see e.g. ticket 2015

Any version of Python 2.7 should be suitable for GRASS. However, it
needs to be installed correctly, and GRASS needs to not attempt to
bundle Python.

GRASS should not use a system-wide Python installation, or more
precisely, should explicitly ignore any system-wide python file
associations. Expecting system-wide python file associations is the
cause of all the trouble.

"Executing" a script uses the registry associations for the script's
extension.

Attempting to by-pass the system's script execution mechanism (by
explicitly executing Python scripts via a specific interpreter) is the
cause of all the trouble.

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

31

On Mon, Jan 27, 2014 at 12:16 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Markus Metz wrote:

On Sat, Jan 25, 2014 at 3:59 PM, Helena Mitasova <hmitaso@ncsu.edu> wrote:
> Just a note, given that most of these problems were caused by conflicts with python installed by ArcGIS,
> I checked with our GIS support and the latest ArcGIS 10.2 installs python2.7 which (I guess) should work with GRASS.

No, there are different versions of Python 2.7, and not all work with
GRASS, see e.g. ticket 2015

Any version of Python 2.7 should be suitable for GRASS.

Not all versions of Python 2.7 are suitable for WinGRASS, see ticket #2150.

However, it
needs to be installed correctly, and GRASS needs to not attempt to
bundle Python.

GRASS should not use a system-wide Python installation, or more
precisely, should explicitly ignore any system-wide python file
associations. Expecting system-wide python file associations is the
cause of all the trouble.

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

Attempting to by-pass the system's script execution mechanism (by
explicitly executing Python scripts via a specific interpreter) is the
cause of all the trouble.

I disagree. Troubles arise if the system's interpreter, e.g. Python
installed by ArcGIS, is used instead of the python version embedded in
WinGRASS.

Markus M

32

As someone who uses both ArcGIS and GRASS on windows, I see it as a bonus that the python installations are separate. I can recommend that folks in my agency install GRASS on a computer and I can assure them that it does not affect their ArcGIS installation, with it’s own ESRI - specific version of python.

Doug

···

On Tue, Jan 28, 2014 at 6:07 AM, Markus Metz <markus.metz.giswork@gmail.com> wrote:

On Mon, Jan 27, 2014 at 12:16 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Markus Metz wrote:

On Sat, Jan 25, 2014 at 3:59 PM, Helena Mitasova <hmitaso@ncsu.edu> wrote:

Just a note, given that most of these problems were caused by conflicts with python installed by ArcGIS,
I checked with our GIS support and the latest ArcGIS 10.2 installs python2.7 which (I guess) should work with GRASS.

No, there are different versions of Python 2.7, and not all work with
GRASS, see e.g. ticket 2015

Any version of Python 2.7 should be suitable for GRASS.

Not all versions of Python 2.7 are suitable for WinGRASS, see ticket #2150.

However, it
needs to be installed correctly, and GRASS needs to not attempt to
bundle Python.

GRASS should not use a system-wide Python installation, or more
precisely, should explicitly ignore any system-wide python file
associations. Expecting system-wide python file associations is the
cause of all the trouble.

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

Attempting to by-pass the system’s script execution mechanism (by
explicitly executing Python scripts via a specific interpreter) is the
cause of all the trouble.

I disagree. Troubles arise if the system’s interpreter, e.g. Python
installed by ArcGIS, is used instead of the python version embedded in
WinGRASS.

Markus M

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

–

Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newcomb@fws.gov

The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.

33

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.

I second this.

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Handling-of-Python-scripts-on-MS-Windows-tp5081335p5100437.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

34

As someone who uses both ArcGIS and GRASS on windows, I see it as a bonus

that the python installations

are separate. I can recommend that folks in my agency install GRASS on a

computer and I can assure them >that it does not affect their ArcGIS
installation, with it's own ESRI - specific version of python.

I second this too.

-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Handling-of-Python-scripts-on-MS-Windows-tp5081335p5100439.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

35

On Tue, Jan 28, 2014 at 1:03 PM, Newcomb, Doug <doug_newcomb@fws.gov> wrote:

As someone who uses both ArcGIS and GRASS on windows, I see it as a bonus
that the python installations are separate. I can recommend that folks in
my agency install GRASS on a computer and I can assure them that it does not
affect their ArcGIS installation, with it's own ESRI - specific version of
python.

I completely agree.
Personally I see a complete isolate python installation as a plus in that case.

Pietro

36

Hi,

2014-01-28 Pietro <peter.zamb@gmail.com>:

On Tue, Jan 28, 2014 at 1:03 PM, Newcomb, Doug <doug_newcomb@fws.gov> wrote:

As someone who uses both ArcGIS and GRASS on windows, I see it as a bonus
that the python installations are separate. I can recommend that folks in
my agency install GRASS on a computer and I can assure them that it does not
affect their ArcGIS installation, with it's own ESRI - specific version of
python.

I completely agree.
Personally I see a complete isolate python installation as a plus in that case.

agreed, it's my opinion from the beginning of this long-term discussion. Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

37

On 28 January 2014 14:30, Martin Landa <landa.martin@gmail.com> wrote:

Hi,

Hi,

2014-01-28 Pietro <peter.zamb@gmail.com>:

I completely agree.
Personally I see a complete isolate python installation as a plus in that case.

agreed, it's my opinion from the beginning of this long-term discussion. Martin

+1

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

38

On Tue, Jan 28, 2014 at 6:07 AM, Markus Metz
<markus.metz.giswork@gmail.com>wrote:

On Mon, Jan 27, 2014 at 12:16 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:
>
> Markus Metz wrote:
>
>> On Sat, Jan 25, 2014 at 3:59 PM, Helena Mitasova <hmitaso@ncsu.edu>
wrote:
>> > Just a note, given that most of these problems were caused by
conflicts with python installed by ArcGIS,
>> > I checked with our GIS support and the latest ArcGIS 10.2 installs
python2.7 which (I guess) should work with GRASS.
>>
>> No, there are different versions of Python 2.7, and not all work with
>> GRASS, see e.g. ticket 2015
>
> Any version of Python 2.7 should be suitable for GRASS.

Not all versions of Python 2.7 are suitable for WinGRASS, see ticket #2150.

Actually, the problem in #2150 is that there is a version mismatch, or mess
is probably a better word: When Python script is called from Python
module/script system association is used (if exists?) and system-wide
python.exe is used, however the Python distribution packages which are used
are from our Python inside GRASS. The current problem is that there is a
incompatibility between Python 2.7.3 and 2.7.4; some import fails because
older system Python library (dll) does not contain MAXREPEAT variable. (To
be honest, now I'm not sure how (dll) library is involved in this. I
remember that even our python.exe was using dll from system Python...)

39

On 28/01/14 16:07, Vaclav Petras wrote:

The current problem is that there
is a incompatibility between Python 2.7.3 and 2.7.4; some import fails
because older system Python library (dll) does not contain MAXREPEAT
variable. (To be honest, now I'm not sure how (dll) library is involved
in this. I remember that even our python.exe was using dll from system
Python...)

I think this is the main issue: AFAIU, unless we completely isolate the GRASS Python environment from the outside, mixes such as can potentially happen.

virtualenv might be a solution to this, but I don't know it enough.

Moritz

40

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