[GRASS-dev] Python handling in winGRASS7 [was: Re: GRASS GIS 7 tech-preview release preparations]

[Moritz Lennert]

On 26/07/13 00:04, Helmut Kudrnovsky wrote:
>> - One of the issues is whether and how to install Python. As Python is
>> needed both for the wxgui and for scripting, and scripting is something
>> for which you cannot assume an embedded Python interpreter, the
>> preferred solution would be to install Python system-wide using the
>> official Python installer (i.e. possibly having the GRASS installer test
>> for Python installation and if not present, propose to launch the
>> download and execution of the official Python installer).
>
> unfortunately and in contrast to Linux/(Mac?), there is 'normally' no
> 'unique' (system-wide) python 2.x/3.x installation in MS windows OS.
>
> windows user software may/may not bring their own embedded/system wide
> installed python versions.
>
> examples for software with embedded python without system wide registry
> entries:
>
> e.g.
> C:\Program Files (x86)\LibreOffice 4.0\program\python-core-3.3.0
> C:\Program Files (x86)\Inkscape\python
> [...]
>
> examples for software with a system wide python installation _and_ with
> registry entries:
>
> e.g.
> C:\Python26\ArcGIS10.0
> C:\Python27\ArcGIS10.1
> [...]

Yes, and AFAIU, especially via the explanations Glynn gave (notably in 
[1]), the difference between the two options is whether you want to

a) use Python only from within the application, i.e. for internal 
scripts (IIUC, in GRASS this would translate to scripted modules and the 
wxGUI), which is the case for Inkscape and LibreOffice

or

b) use Python also for command line scripting in the general environment 
and so install Python system wide (e.g. ArcGIS). In the idea that 
scripts that call GRASS functions should run also when called from 
outside a running GRASS "session", this would be the preferable way for us.

However, again IIUC, a) is much easier to implement via an embedded 
Python interpreter, while b) causes the issues you mention concerning 
library incompatibilities and the need to install missing necessary 
Python packages.

So the big question is whether we think we can solve the issues related 
to b) with a reasonable effort.

Would it be a possible option to implement only a) and document the fact 
that the user has to take care of creating a working Python installation 
herself if they want b) ?

Moritz



[1] https://trac.osgeo.org/grass/ticket/580#comment:53