python-scripts in wingrass64svn

[hellik]

how is the best way to start/launch additional python-scipts in standalone wingrass642 (not yet tested in osgeo4w-wingrass)

tested and working examples of python-scipts

http://grass.osgeo.org/wiki/GRASS_AddOns#r.basin http://grass.osgeo.org/wiki/GRASS_AddOns#r.ipso http://grass.osgeo.org/wiki/GRASS_AddOns#r.wf

r.basin.py invokes r.ipso.py and r.wf

(also needed for test: all r.stream*-addons: http://grass.osgeo.org/wiki/GRASS_AddOns#r.stream.angle http://grass.osgeo.org/wiki/GRASS_AddOns#r.stream.basins http://grass.osgeo.org/wiki/GRASS_AddOns#r.stream.del http://grass.osgeo.org/wiki/GRASS_AddOns#r.stream.distance http://grass.osgeo.org/wiki/GRASS_AddOns#r.stream.extract http://grass.osgeo.org/wiki/GRASS_AddOns#r.stream.order http://grass.osgeo.org/wiki/GRASS_AddOns#r.stream.pos http://grass.osgeo.org/wiki/GRASS_AddOns#r.stream.stats)

all case studies with a self compiled wingrass64svn (newly based on python272) tested on a WinVista?32-box without any installed stock python, only the wingrass-bundled.

working example in the nc-sample-dataset (sqlite as vector-db-backend needed):

g.region -a rast=elevation@PERMANENT  
r.basin --verbose map=elevation@PERMANENT prefix=a easting=637515 northing=224615 threshold=50

---

case study (1)

r.basin.py,r.ipso.py,r.wf.py manually added in C:\Program Files\GRASS 6.4.2svn\scripts r.basin.bat,r.ipso.bat,r.wf.bat manually added in C:\Program Files\GRASS 6.4.2svn\bin

the content of the bat-files:

@"%GRASS_PYTHON%" "%GISBASE%/scripts/r.basin.py" %*
@"%GRASS_PYTHON%" "%GISBASE%/scripts/r.ipso.py" %*
@"%GRASS_PYTHON%" "%GISBASE%/scripts/r.wf.py" %*

it's needed to change in r.basin.py

from

        grass.message( "##################################" )
        grass.run_command('r.wf.py', map = r_distance, 
                                 image = prefix) 
        grass.message( "##################################" )                         
        
        # Ipsographic curve
        grass.message( "##################################" )
        grass.run_command('r.ipso.py', map = 'r_elevation_crop', 
                                   image = prefix, 
                                   flags = 'ab')

to

 grass.message( "##################################" )
        grass.run_command('r.wf', map = r_distance, 
                                 image = prefix) 
        grass.message( "##################################" )                         
        
        # Ipsographic curve
        grass.message( "##################################" )
        grass.run_command('r.ipso', map = 'r_elevation_crop', 
                                   image = prefix, 
                                   flags = 'ab')

(1)a => following command in the wxgui-command-line is working

r.basin --verbose map=elevation@PERMANENT prefix=a easting=637515 northing=224615 threshold=50
ABSCHNITT 1a (von 4): Initiiere den Speicher.
ABSCHNITT 1b (of 4): Ermittle den Fluß aus der Karte heraus.
[...]
Bifurcation Ratio (Horton) :   3.5606
Length Ratio (Horton) :   2.3439
Area ratio (Horton) :    3.3353
Slope ratio (Horton):   1.3381
##################################
Done!

(1)b => only r.basin in the wxgui-command-line, r.basin-wxgui is starting, but by starting r.basin from his r.basin-wxgui, it's interpreted as

r.basin.py map=elevation@PERMANENT prefix=b easting=637515 northing=224615 threshold=50

and there is following error:

r.basin.py map=elevation@PERMANENT prefix=b easting=637515 northing=224615 threshold=50 C:\Program Files\GRASS 6.4.2svn\extrabin\python.exe: can't open file 'r.basin.py': [Errno 2] No such file or directory

---

case study (2)

r.basin.py, r.ipso.py, r.wf.py are in i.e. c:\grassscripts

File -> Launch script: c:\grassscripts\r.basin.py

=> r.basin-wxgui is starting, but by starting r.basin from his r.basin-wxgui, again the same error like above:

r.basin.py map=elevation@PERMANENT prefix=a easting=637515 northing=224615 threshold=50 C:\Program Files\GRASS 6.4.2svn\extrabin\python.exe: can't open file 'r.basin.py': [Errno 2] No such file or directory

---

case study (3)

scripts installed by g.extension

g.extension.py extension=r.basin svnurl= http://svn.osgeo.org/grass/grass-addons/grass6 Downloading precompiled GRASS Addons <r.basin>... Updating metadata file... Installation of <r.basin> successfully finished

g.extension.py extension=r.ipso svnurl= http://svn.osgeo.org/grass/grass-addons/grass6 Downloading precompiled GRASS Addons <r.ipso>... Updating metadata file... Installation of <r.ipso> successfully finished

g.extension.py extension=r.wf svnurl= http://svn.osgeo.org/grass/grass-addons/grass6 Downloading precompiled GRASS Addons <r.wf>... Updating metadata file... Installation of <r.wf> successfully finished

the addons are installed:

C:\Users\syringia\AppData\Roaming\GRASS6\addons

	bin
	docs
	modules.xml
	r.ipso.py
	r.wf.py

C:\Users\syringia\AppData\Roaming\GRASS6\addons\bin	
	
	r.basin.py.bat
	r.ipso.py.bat
	r.wf.py.bat

the content of the bat-files:

@"%GRASS_SH%" "%GISBASE%/scripts/r.basin.py" %*
@"%GRASS_SH%" "%GISBASE%/scripts/r.ipso.py" %*
@"%GRASS_SH%" "%GISBASE%/scripts/r.wf.py" %*

(3)a => r.basin in the wxgui-command-line, a window pops up because .py is an ankown extension and it's asked how to open

(3)b => r.basin.py in the wxgui-command-line, again following error:

C:\Program Files\GRASS 6.4.2svn\extrabin\python.exe: can't open file 'r.basin.py': [Errno 2] No such file or directory

---

any ideas how the situation for python-script in wingrass642 can be improved?

so it seems the corresponding wrapper-bat-files should at least contain "%GRASS_PYTHON%" instead of "%GRASS_SH%"

Helmut

[hamish]

fwiw-

• python scripts are not currently handled by the GRASS 6 Make system; any .bat file automatically built using the default: script Makefile target will be assumed to be a shell script. Any grass6 python script using that Makefile target will create a .bat file which thinks it's dealing with a shell script. It would be nice to have a python_script target to work with.

• the language a module is written in is irrelevant to the end-user, and so "g.module" should be the name the user sees/runs regardless if it is .exe, .bat, .sh, or .py behind the scenes.

... but how to accomplish that?

IIUC the need for .bat wrapper in WinGrass is that associating .py with our copy of python at install time applies itself system wide (%PATHEXT% and/or in the registry), which could break other software on the user's system which are expecting another version of python to be used. (the 'last software to be installed wins' experience)

perhaps of interest,  http://code.google.com/p/winsys/source/browse/trunk/random/associate.py?r=526

• fwiw g.extension.sh strips the .py extension off of modules at install time since there is no Makefile target to do the job. I don't think g.extension.py currently does that, but I would suggest that it probably should. (at least on unix; ideally the filename becomes invisible to the end-user on Windows and they just see/use the module name at run-time)

Hamish

[glynn]

Replying to hamish:

... but how to accomplish that?

Regarding GRASS 7:

The "right" way is to require that a compatible version of Python is correctly installed on the system and to ensure that PATHEXT contains the ".PY" extension.

This won't work with MSys, but failing to honour PATHEXT is MSys' bug, and not something we should be trying to work around. If anyone is that determined to use MSys, they are free to provide an MSys package for GRASS, distinct from the native Windows version.

It isn't possible to avoid the requirement for a "system" Python installation without putting GRASS inside a "ghetto" where it will never be able to fully integrate with the rest of the system.

Unfortunately, it isn't going to be feasible to avoid that for 6.x.

[hellik]

Replying to glynn:

Replying to hamish:

... but how to accomplish that?

Regarding GRASS 7: The "right" way is to require that a compatible version of Python is correctly installed on the system and to ensure that PATHEXT contains the ".PY" extension.

[...]

It isn't possible to avoid the requirement for a "system" Python installation >without putting GRASS inside a "ghetto" where it will never be able to fully >integrate with the rest of the system.

I understand that one installed "right" system-python would be a quite nice thing.

Hamish:

...which could break other software on the user's system which are expecting another version of python to be used. (the 'last software to be installed wins' experience)

just a very quick but not complete look for references to a (bundled) python here on my winvista-box regarding the windows side of python-life:

[...]
C:\Program Files\Inkscape\python\
C:\Program Files\GRASS 6.4.2svn\Python27
C:\Program Files\GRASS 7.0.svn\Python27
C:\Program Files\LibreOffice 3.4\Basis\program\python-core-2.6.1
C:\Program Files\OpenOffice.org 3\Basis\program\python-core-2.6.1
[...]

anyway, any hints/ideas how the others open source projects (i.e. also windows-version of qgis) solve this python-version-issue?

Helmut

[glynn]

Replying to hellik:

just a very quick but not complete look for references to a (bundled) python here on my winvista-box regarding the windows side of python-life:

C:\Program Files\Inkscape\python\
C:\Program Files\LibreOffice 3.4\Basis\program\python-core-2.6.1
C:\Program Files\OpenOffice.org 3\Basis\program\python-core-2.6.1

The situation for a monolithic GUI application isn't comparable. These programs "embed" a Python interpreter in order to provide scripting capabilities within the application, in the same way that a web browser embeds a JavaScript interpreter.

GRASS' Python scripts are meant to fulfil the same role as Unix shell scripts or Windows batch files, but portably (and without the ANSI/OEM-codepage nonsense that batch files have).

[hellik]

Replying to hellik:

---- case study (3) scripts installed by g.extension g.extension.py extension=r.basin svnurl= http://svn.osgeo.org/grass/grass-addons/grass6 Downloading precompiled GRASS Addons <r.basin>... Updating metadata file... Installation of <r.basin> successfully finished g.extension.py extension=r.ipso svnurl= http://svn.osgeo.org/grass/grass-addons/grass6 Downloading precompiled GRASS Addons <r.ipso>... Updating metadata file... Installation of <r.ipso> successfully finished g.extension.py extension=r.wf svnurl= http://svn.osgeo.org/grass/grass-addons/grass6 Downloading precompiled GRASS Addons <r.wf>... Updating metadata file... Installation of <r.wf> successfully finished the addons are installed: {{{ C:\Users\syringia\AppData?\Roaming\GRASS6\addons bin docs modules.xml r.ipso.py r.wf.py }}} {{{ C:\Users\syringia\AppData?\Roaming\GRASS6\addons\bin r.basin.py.bat r.ipso.py.bat r.wf.py.bat }}} the content of the bat-files: {{{ @"%GRASS_SH%" "%GISBASE%/scripts/r.basin.py" %* @"%GRASS_SH%" "%GISBASE%/scripts/r.ipso.py" %* @"%GRASS_SH%" "%GISBASE%/scripts/r.wf.py" %* }}} (3)a => r.basin in the wxgui-command-line, a window pops up because .py is an ankown extension and it's asked how to open (3)b => r.basin.py in the wxgui-command-line, again following error: C:\Program Files\GRASS 6.4.2svn\extrabin\python.exe: can't open file 'r.basin.py': [Errno 2] No such file or directory ---- any ideas how the situation for python-script in wingrass642 can be improved? so it seems the corresponding wrapper-bat-files should at least contain "%GRASS_PYTHON%" instead of "%GRASS_SH%"

still relevant...

[hamish]

see also #1768