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

On Tue, Jan 28, 2014 at 3:52 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

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.

I'm using virtualenv daily to isolate GRASS on my system (linux), but
still I'm not sure if could be the solution for windows users. I guess
could be a solution if we create a setup.py file using setuptools [0]
transforming GRASS into a normal python package (like: numpy, gdal,
proj4, etc.).

In this way all the Mac/Linux/windows users should be able to install
GRASS and all its dependencies with:

$ easy_install grass

or using pip

$ pip install grass

But I've never used setuptools so I don't have the knowledge to set
and configure a setup.py file for such complex project like GRASS.

Pietro

[0] https://pypi.python.org/pypi/setuptools

Hi All,

On 28/01/14 17:05, Moritz Lennert wrote:

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.

This matters for using os.system("python.exe <script>") from within
a Python script, right?

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 I think that part should never be changed.

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.

FWIW, I would start by modifying %PATH% before running os.system(),
so that the bundled python.exe and all of its DLLs are in the Windows
path, preceeding any other folders from which a system-wide Python
could pick them up. Worth a try, I think, before moving on to more
complex solutions. In addition, one should probably never use
os.system("python.exe"), but rather os.system("path-to-bundled-
python\python.exe")

If this helps, it would be straight-forward to replace
all os.system() calls in all existing scripts with a version that
first sets the path correctly -- and then never use os.system()
directly in a GRASS script.

Another approach would be to have GRASS modify the local registry
settings for the Python shell association, then restore the previous
settings upon exit -- but that would be rather messy.

Best,

Ben

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

On Tue, Jan 28, 2014 at 5:13 PM, Pietro <peter.zamb@gmail.com> wrote:

On Tue, Jan 28, 2014 at 3:52 PM, Moritz Lennert
<mlennert@club.worldonline.be> wrote:

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.

I'm using virtualenv daily to isolate GRASS on my system (linux), but
still I'm not sure if could be the solution for windows users. I guess
could be a solution if we create a setup.py file using setuptools [0]
transforming GRASS into a normal python package (like: numpy, gdal,
proj4, etc.).

In this way all the Mac/Linux/windows users should be able to install
GRASS and all its dependencies with:

$ easy_install grass

or using pip

$ pip install grass

I am afraid this does not work if there is no system-wide python
installation. Moreover, how would easy_install and pip know that they
should use GRASS_PYTHON? I mean,
$ pip install grass
could then only work if GRASS with GRASS_PYTHON is already installed?

Markus M

But I've never used setuptools so I don't have the knowledge to set
and configure a setup.py file for such complex project like GRASS.

Pietro

[0] https://pypi.python.org/pypi/setuptools

Trying a summary on this discussion.

AFAIU, the whole discussion boils down to the question if we want to
require a system-wide installation of Python with correct python file
associations in the registry, potentially deactivating an existing
Python installation, or not.

There seems to be agreement that we do not want to modify any existing
system-wide python installation.

That means that WinGRASS should
1) not do a system-wide installation of Python
2) not require a system-wide Python installation
3) explicitly ignore any existing system-wide installation of Python,
or any Python file associations in the registry (text-editor,
whatever)

That means that we must assume that Windows has no idea what to do
with Python files, and if it has an idea, this is most probably a bad
idea, as far as GRASS scripts are concerned. As for shell scripts in
GRASS 6. That in turn means that GRASS Python scripts must be called
explicitly with GRASS_PYTHON, most importantly scripts from within
scripts.

IMHO, creating .bat files for python scripts is easy because the
equivalent is already working for WinGRASS 6.4 where .bat files are
created for shell scripts. AFAICT none of the other suggestions
(virtualenv, Python launcher, pip, etc) has been tested successfully
on Windows with GRASS 7, both with and without a separate incompatible
system-wide Python installation.

Markus M

On Tue, Jan 28, 2014 at 2:57 PM, Markus Metz
<markus.metz.giswork@gmail.com>wrote:

Trying a summary on this discussion.

AFAIU, the whole discussion boils down to the question if we want to
require a system-wide installation of Python with correct python file
associations in the registry, potentially deactivating an existing
Python installation, or not.

There seems to be agreement that we do not want to modify any existing
system-wide python installation.

That means that WinGRASS should
1) not do a system-wide installation of Python
2) not require a system-wide Python installation
3) explicitly ignore any existing system-wide installation of Python,
or any Python file associations in the registry (text-editor,
whatever)

That means that we must assume that Windows has no idea what to do
with Python files, and if it has an idea, this is most probably a bad
idea, as far as GRASS scripts are concerned. As for shell scripts in
GRASS 6. That in turn means that GRASS Python scripts must be called
explicitly with GRASS_PYTHON, most importantly scripts from within
scripts.

IMHO, creating .bat files for python scripts is easy because the
equivalent is already working for WinGRASS 6.4 where .bat files are
created for shell scripts. AFAICT none of the other suggestions
(virtualenv, Python launcher, pip, etc) has been tested successfully
on Windows with GRASS 7, both with and without a separate incompatible
system-wide Python installation.

Thanks for the summary.

About the bat files: I just realized I cannot run v.colors on Windows in
grass 6.4.4svn because v.colors is a bash script and inside it calls
another bash script (v.db.addcol) and it can't find it. I saw some pretty
old discussion on this topic [1]. I will create a ticket (I couldn't find
any). I am not sure if this is related to what you are suggesting but I
would like to mention it before we decide to go with bat files.

Anna

[1] http://lists.osgeo.org/pipermail/grass-user/2010-November/058654.html

Hi Markus,

On Tue, Jan 28, 2014 at 7:25 PM, Markus Metz
<markus.metz.giswork@gmail.com> wrote:

In this way all the Mac/Linux/windows users should be able to install
GRASS and all its dependencies with:

$ easy_install grass

or using pip

$ pip install grass

I am afraid this does not work if there is no system-wide python
installation.

yes, this possible solution could work only if you have installed
setuptools and easy_install or pip on your interpreter. The python
interpreter must be already installed somehow.

Moreover, how would easy_install and pip know that they
should use GRASS_PYTHON? I mean,
$ pip install grass
could then only work if GRASS with GRASS_PYTHON is already installed?

Of course neither easy_install or pip know nothing about GRASS and
GRASS_PYTHON, they need only an interpreter to download all the
dependencies, compile, and install GRASS on your system.
Then if you want to run your GRASS program you have to use the right
interpreter, nothing more, nothing less.
Probably could be just an easier way to allow user to choose, and be
conscious of which python interpreter (or virtual environment) will be
used by GRASS.

Anyway, I don't think that setuptools could be the solution for our
problems, at least not in the short term. And I agree with you,
creating .bat files, it seems the best/easier solution so far.

Pietro

ps: Small note: python 3.3 insert the native support for virtual
environment in the standard library
(http://docs.python.org/3/library/venv.html).

Markus Metz wrote:

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

To the extent that I can make any sense of that ticket, it appears to
relate to issues caused by attempting to bundle Python.

Bundling the exact same version which is installed system-wide will
obviously hide some of the problems.

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

The registry associations are set by the Python installer. This is why
you can't reasonably bundle Python.

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

Most of the troubles arise from attempting to use a mixture of a
bundled version and a system-wide installation. Which wouldn't be an
issue if people didn't attempt to bundle Python.

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

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

If only such a thing were actually possible. It isn't.

Because execution of scripts uses the registry, it isn't possible to
control the interpreter used on a per-process basis.

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

Benjamin Ducke wrote:

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

This matters for using os.system("python.exe <script>") from within
a Python script, right?

No. It matters for using e.g. os.system("/path/to/script.py") from a
Python script. Or system("/path/to/script.py") from a C program. Or
just "script.py" from a .bat file. Or any other situation where you
"execute" a script without specifying the interpreter explicitly.

On Unix, the #! line at the start of the script is used to determine
the interpreter. On Windows, the extension is used to look up the
interpreter in the registry.

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

Markus Metz wrote:

AFAIU, the whole discussion boils down to the question if we want to
require a system-wide installation of Python with correct python file
associations in the registry, potentially deactivating an existing
Python installation, or not.

There seems to be agreement that we do not want to modify any existing
system-wide python installation.

That means that WinGRASS should
1) not do a system-wide installation of Python

It should not blindly replace or modify any system-wide installation.

2) not require a system-wide Python installation

It needs a system-wide Python installation if Python scripts are to be
"first-class citizens", i.e. having the same capabilities as a
compiled program. This is an OS requirement which GRASS cannot avoid.

If you don't do this, "WinGRASS" will always be a second-class citizen
compared to the real (i.e. Unix) GRASS.

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

(stating the obvious)

The findings should be summarized in a Wiki page..

Markus

Glynn Clements wrote:

Markus Metz wrote:

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

The registry associations are set by the Python installer. This is why
you can't reasonably bundle Python.

GRASS does not come with a Python installer.

Other projects such as gimp or libreoffice are AFAICT reasonably
bundled with Python, without a Python installer.

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

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.

Which wouldn't be an
issue if people didn't attempt to bundle Python.

Other projects do bundle Python, and there it seems to work just fine.

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

Otherwise, users would need to install Python, wxPython, numpy, scipy,
matplotlib, datetime themselves (not sure if the list is correct and
complete).

Markus M

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

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.

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

But this only works for a closed system which knows what it is
executing. It doesn't help us provide a command-line environment where
Python scripts just work as they should.

> Which wouldn't be an
> issue if people didn't attempt to bundle Python.

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 don't understand why we can not also bundle Python, including all
required Python packages.

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.

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.

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

On 04/02/14 11:29, Glynn Clements wrote:

Markus Metz wrote:

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.

But this only works for a closed system which knows what it is
executing. It doesn't help us provide a command-line environment where
Python scripts just work as they should.

I think this is the basis of some of the frustration in the ongoing discussion: different use-cases and philosophies about what GRASS is and should be. I understand that for many users (and I would guess for part of the developers), GRASS _is_ a monolithic system and Python scripts are only used from within, but for others the fact that it is a more open, modular system makes for a large part of its attractiveness. So, the solution we have to find has to cater to both, and unfortunately, embedding Python will not suffice for the second use case.

I do have the feeling, though, that the python launcher is an interesting path to explore.

Moritz

Hi there,

On 04/02/14 13:24, Moritz Lennert wrote:

On 04/02/14 11:29, Glynn Clements wrote:

Markus Metz wrote:

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.

But this only works for a closed system which knows what it is
executing. It doesn't help us provide a command-line environment where
Python scripts just work as they should.

I think this is the basis of some of the frustration in the ongoing
discussion: different use-cases and philosophies about what GRASS is and
should be. I understand that for many users (and I would guess for part
of the developers), GRASS _is_ a monolithic system and Python scripts
are only used from within, but for others the fact that it is a more
open, modular system makes for a large part of its attractiveness. So,
the solution we have to find has to cater to both, and unfortunately,
embedding Python will not suffice for the second use case.

That's a really important point! GRASS is an example of
the Unix tradition of modular design. It owed and continues
to owe much of its flexibility to this fact. From my
point of view, its clean, modular architecture is also what
has given GRASS its amazing lifespan and maintainability.

The GUI design should never compromise that. In fact,
I believe the GUI is a matter of choice/taste and
should be exchangeable at will. We have GRASS running
as a processing backend for WPS and for several "host"
desktop GIS (QGIS, OpenJUMP, Kosmo, uDig, gvSIG, ...).

E.g., I use GRASS exclusively either through the command
line or via the GRASS plug-in in gvSIG CE. But with the
latest Python developments, it will be a real challenge to
integrate GRASS 7 in the same way that we could integrate
GRASS 6 into a "host" application (i.e. without messing
around with any system settings).

Best,

Ben

I do have the feeling, though, that the python launcher is an
interesting path to explore.

Moritz

_______________________________________________
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

On Tue, Feb 4, 2014 at 8:25 AM, Benjamin Ducke <benducke@fastmail.fm> wrote:

But with the
latest Python developments, it will be a real challenge to
integrate GRASS 7 in the same way that we could integrate
GRASS 6 into a "host" application (i.e. without messing
around with any system settings).

Can you be more specific? It sounds like something we should be concern
about. We should consider how GRASS 7 will be integrated into other GIS
packages when Python scripts are called this or that way.

On 04/02/14 15:09, Vaclav Petras wrote:

On Tue, Feb 4, 2014 at 8:25 AM, Benjamin Ducke <benducke@fastmail.fm
<mailto:benducke@fastmail.fm>> wrote:

    But with the
    latest Python developments, it will be a real challenge to
    integrate GRASS 7 in the same way that we could integrate
    GRASS 6 into a "host" application (i.e. without messing
    around with any system settings).

Can you be more specific? It sounds like something we should be concern
about. We should consider how GRASS 7 will be integrated into other GIS
packages when Python scripts are called this or that way.

Sure. At this moment, we (i.e. the gvSIG CE dev team) distribute
GRASS 6 binaries along with gvSIG CE. On Windows, we also package
MSYS with "sh.exe" for the scripted modules.

So we can deliever gvSIG CE + GRASS as a completely self-contained
(portable) package.

Of course, we do not ship any GRASS GUI (or any of the d.* modules).
All GRASS modules are available seamlessly from the gvSIG CE GUI via a
Plug-in, similar to that in QGIS.

Now, with the new Python-scripted modules in GRASS 7 this will
become more difficult, since Python adds a more heavy dependency.
In order to stay portable, we need to bundle a completely isolated
Python interpreter with gvSIG CE. And then we also need to make
sure that no GRASS Python module will call the system Python. The
latter is something that can only be taken care of on the GRASS
side.

Years ago, when the development of the wxGUI started to get more
integrated with that of GRASS itself, it was suggested by some
to completely separate the GUI development.I still think that
would be a good idea.

Best,

Ben

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

  benducke@fastmail.fm

On Tue, Feb 4, 2014 at 10:14 AM, Benjamin Ducke <benducke@fastmail.fm>wrote:

Years ago, when the development of the wxGUI started to get more
integrated with that of GRASS itself, it was suggested by some
to completely separate the GUI development.I still think that
would be a good idea.

If you want open this topic, please do so now or anytime later. I'm willing
to discuss it and if the last discussion about this was long time ago, it
would be probably healthy to estimate what is the state and what are our
goals.

Vaclav

On Tue, Feb 4, 2014 at 10:14 AM, Benjamin Ducke <benducke@fastmail.fm>wrote:

On 04/02/14 15:09, Vaclav Petras wrote:
>
> On Tue, Feb 4, 2014 at 8:25 AM, Benjamin Ducke <benducke@fastmail.fm
> <mailto:benducke@fastmail.fm>> wrote:
>
> But with the
> latest Python developments, it will be a real challenge to
> integrate GRASS 7 in the same way that we could integrate
> GRASS 6 into a "host" application (i.e. without messing
> around with any system settings).
>
>
> Can you be more specific? It sounds like something we should be concern
> about. We should consider how GRASS 7 will be integrated into other GIS
> packages when Python scripts are called this or that way.

Sure. At this moment, we (i.e. the gvSIG CE dev team) distribute
GRASS 6 binaries along with gvSIG CE. On Windows, we also package
MSYS with "sh.exe" for the scripted modules.

So we can deliever gvSIG CE + GRASS as a completely self-contained
(portable) package.

Of course, we do not ship any GRASS GUI (or any of the d.* modules).
All GRASS modules are available seamlessly from the gvSIG CE GUI via a
Plug-in, similar to that in QGIS.

Now, with the new Python-scripted modules in GRASS 7 this will
become more difficult, since Python adds a more heavy dependency.
In order to stay portable, we need to bundle a completely isolated
Python interpreter with gvSIG CE. And then we also need to make
sure that no GRASS Python module will call the system Python. The
latter is something that can only be taken care of on the GRASS
side.

So, what would be the consequences for gvSIG, QGIS, OSGeo4W, ... if we
decide to use system Python in (standalone) WinGRASS?

On 04/02/14 16:42, Vaclav Petras wrote:

On Tue, Feb 4, 2014 at 10:14 AM, Benjamin Ducke <benducke@fastmail.fm
<mailto:benducke@fastmail.fm>> wrote:

    On 04/02/14 15:09, Vaclav Petras wrote:
    >
    > On Tue, Feb 4, 2014 at 8:25 AM, Benjamin Ducke
    <benducke@fastmail.fm <mailto:benducke@fastmail.fm>
    > <mailto:benducke@fastmail.fm>> wrote:
    >
    > But with the
    > latest Python developments, it will be a real challenge to
    > integrate GRASS 7 in the same way that we could integrate
    > GRASS 6 into a "host" application (i.e. without messing
    > around with any system settings).
    >
    >
    > Can you be more specific? It sounds like something we should be
    concern
    > about. We should consider how GRASS 7 will be integrated into
    other GIS
    > packages when Python scripts are called this or that way.

    Sure. At this moment, we (i.e. the gvSIG CE dev team) distribute
    GRASS 6 binaries along with gvSIG CE. On Windows, we also package
    MSYS with "sh.exe" for the scripted modules.

    So we can deliever gvSIG CE + GRASS as a completely self-contained
    (portable) package.

    Of course, we do not ship any GRASS GUI (or any of the d.* modules).
    All GRASS modules are available seamlessly from the gvSIG CE GUI via a
    Plug-in, similar to that in QGIS.

    Now, with the new Python-scripted modules in GRASS 7 this will
    become more difficult, since Python adds a more heavy dependency.
    In order to stay portable, we need to bundle a completely isolated
    Python interpreter with gvSIG CE. And then we also need to make
    sure that no GRASS Python module will call the system Python. The
    latter is something that can only be taken care of on the GRASS
    side.

So, what would be the consequences for gvSIG, QGIS, OSGeo4W, ... if we
decide to use system Python in (standalone) WinGRASS?

As far as gvSIG CE is concerned, there would be no consequences,
as long as it is possible to also make a GRASS distribution that
does not depend on system Python.

We ship our own, bundled GRASS binaries and users can just install
a WinGRASS (or any other GRASS version) in parallel. However,
in order to be able to bundle GRASS 7 in the future, none
of its modules should depend on system Python. If there were such
a dependency, then we would have to drop the Python-scripted
modules from the set of GRASS modules supported in gvSIG CE, as
we do not want to compromise our software's portability.

Best,

Ben

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

  benducke@fastmail.fm