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

[Vaclav Petras]

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

> On 04/02/14 15:09, Vaclav Petras wrote:
> >
> > On Tue, Feb 4, 2014 at 8:25 AM, Benjamin Ducke <benducke at fastmail.fm
> > <mailto:benducke at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140204/655a9e45/attachment.html>