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

[Benjamin Ducke]

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.

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 at fastmail.fm