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

[Helmut Kudrnovsky]

hi Moritz,

>Is this a correct summary of the issues ? Anything I'm missing ?

thanks for the summary, some additions below.

>
>On 12/07/13 23:50, Helmut Kudrnovsky wrote:
>>> - the python issues in wingrass (notably how to correctly install python
>>> to be able to launch scripts and addons)
>>
>> IMHO it's one of the showstoppers in winGRASS7
>>
>> not only correctly installing python, but also what is the
>> structure/approach in C:\Users\xxxx\AppData\Roaming\GRASS7\addons\ of
>> installing python-scripts and bat-wrappers and also related the
>> make-files
>> for addons
>
>I'm currently trying to understand all the issues concerning Python in 
>wingrass (I don't think there are any issues concerning Python in 
>GNU/Linux, don't know about Mac). Here's what I've understood so far:
>
>- 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
[...]

if some user software does a system wide installation and registry entries,
the py-extension may be registered for this python version. py-extension
registered in the MS windows registry may get precedence before a python of
the same version embedded in a user software.

e.g. here in my Win7-box ArcGIS10.1 does a system wide registry entry for
python 2.7 (see above) and therefore the standalone-WinGRASS 7-installer
with an embedded python 2.7 doesn't start because of a mismatch of some
lib/etc.

so the question will be what could a working python installation/python
mechanism for standalone WinGRASS/OSGeo4W-WinGRASS be without interefering
with other software already using python (systemwide/embedded) in order to
avoid the actual quirks ....

>This also 
>entails the necessity to download and install the relevant packages 
>(wxPython, numpy, etc).

maybe yes/no ... depends of the solution. my ambition would be that all GIS
software on my Win7-laptop which using (the same/similar embedded/system
wide) python versions are working without interefering ... ;o)

>- Another issue is how to make it possible in windows to launch modules 
>that are Python scripts by simply calling their module name, without .py 
>extension. At this stage, in a fresh installation of GRASS7 on WinXP, I 
>can launch (and successfully execute) python scripts from the wxGUI menu 
>or the wxGUI command console, but not from the windows terminal. 
>However, calling a script from a script (e.g. v.db.dropcolumn called 
>from v.db.renamecolumn) does not work.

yes ... and as described above, not every windows system is 'fresh'...

>- A third issue, related to the previous IIUC, is how to integrate (i.e. 
>make launchable) script addons.

yes

... all logical? ... not always for me ... :o(




-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-GRASS-GIS-7-tech-preview-release-preparations-tp5066002p5068830.html
Sent from the Grass - Dev mailing list archive at Nabble.com.