On Tue, Feb 4, 2014 at 10:14 AM, Benjamin Ducke <[email protected]>wrote:
> On 04/02/14 15:09, Vaclav Petras wrote: > > > > On Tue, Feb 4, 2014 at 8:25 AM, Benjamin Ducke <[email protected] > > <mailto:[email protected]>> 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?
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
