[GRASS-dev] [GRASS GIS] #1555: python-scripts in wingrass64svn

#1555: python-scripts in wingrass64svn
--------------------------------------+-------------------------------------
Reporter: hellik | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 6.4.2
Component: Python | Version: 6.4.2 RCs
Keywords: wingrass, python scripts | Platform: MSWindows Vista
      Cpu: x86-32 |
--------------------------------------+-------------------------------------
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 WinVista32-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

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1555&gt;
GRASS GIS <http://grass.osgeo.org>

#1555: python-scripts in wingrass64svn
--------------------------------------+-------------------------------------
Reporter: hellik | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 6.4.2
Component: Python | Version: 6.4.2 RCs
Keywords: wingrass, python scripts | Platform: MSWindows Vista
      Cpu: x86-32 |
--------------------------------------+-------------------------------------

Comment(by 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

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1555#comment:1&gt;
GRASS GIS <http://grass.osgeo.org>

#1555: python-scripts in wingrass64svn
--------------------------------------+-------------------------------------
Reporter: hellik | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 6.4.2
Component: Python | Version: 6.4.2 RCs
Keywords: wingrass, python scripts | Platform: MSWindows Vista
      Cpu: x86-32 |
--------------------------------------+-------------------------------------

Comment(by glynn):

Replying to [comment:1 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.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1555#comment:2&gt;
GRASS GIS <http://grass.osgeo.org>

#1555: python-scripts in wingrass64svn
--------------------------------------+-------------------------------------
Reporter: hellik | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 6.4.2
Component: Python | Version: 6.4.2 RCs
Keywords: wingrass, python scripts | Platform: MSWindows Vista
      Cpu: x86-32 |
--------------------------------------+-------------------------------------

Comment(by hellik):

Replying to [comment:2 glynn]:
> Replying to [comment:1 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

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1555#comment:3&gt;
GRASS GIS <http://grass.osgeo.org>

#1555: python-scripts in wingrass64svn
--------------------------------------+-------------------------------------
Reporter: hellik | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 6.4.2
Component: Python | Version: 6.4.2 RCs
Keywords: wingrass, python scripts | Platform: MSWindows Vista
      Cpu: x86-32 |
--------------------------------------+-------------------------------------

Comment(by glynn):

Replying to [comment:3 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).

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1555#comment:4&gt;
GRASS GIS <http://grass.osgeo.org>

#1555: python-scripts in wingrass64svn
--------------------------------------+-------------------------------------
Reporter: hellik | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 6.4.2
Component: Python | Version: 6.4.2 RCs
Keywords: wingrass, python scripts | Platform: MSWindows Vista
      Cpu: x86-32 |
--------------------------------------+-------------------------------------

Comment(by hellik):

Replying to [ticket:1555 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...

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1555#comment:5&gt;
GRASS GIS <http://grass.osgeo.org>

#1555: python-scripts in wingrass64svn
--------------------------------------+-------------------------------------
Reporter: hellik | Owner: grass-dev@…
     Type: defect | Status: new
Priority: normal | Milestone: 6.4.4
Component: Python | Version: 6.4.2 RCs
Keywords: wingrass, python scripts | Platform: MSWindows Vista
      Cpu: x86-32 |
--------------------------------------+-------------------------------------
Changes (by hamish):

  * milestone: 6.4.2 => 6.4.4

Comment:

see also #1768

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1555#comment:6&gt;
GRASS GIS <http://grass.osgeo.org>

#1555: python-scripts in wingrass64svn
---------------------+--------------------------------------
  Reporter: hellik | Owner: grass-dev@…
      Type: defect | Status: new
  Priority: normal | Milestone: 6.4.4
Component: Python | Version: 6.4.2 RCs
Resolution: | Keywords: wingrass, python scripts
       CPU: x86-32 | Platform: MSWindows Vista
---------------------+--------------------------------------

Comment (by wenzeslaus):

This was changed heavily and it shouldn't be issue anymore and I would
just close it. However, it is so critical and so problematic that it would
be better to get it confirmed. Is the //case study 3// still relevant?

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1555#comment:7&gt;
GRASS GIS <http://grass.osgeo.org>

#1555: python-scripts in wingrass64svn
---------------------+--------------------------------------
  Reporter: hellik | Owner: grass-dev@…
      Type: defect | Status: new
  Priority: normal | Milestone: 6.4.4
Component: Python | Version: 6.4.2 RCs
Resolution: | Keywords: wingrass, python scripts
       CPU: x86-32 | Platform: MSWindows Vista
---------------------+--------------------------------------

Comment (by hellik):

Replying to [comment:7 wenzeslaus]:
> This was changed heavily and it shouldn't be issue anymore and I would
just close it. However, it is so critical and so problematic that it would
be better to get it confirmed. Is the //case study 3// still relevant?

I've heavily used r.basin in the last days; no problems so far.

a quick test with

{{{
System Info
GRASS Version: 7.0.0
GRASS SVN Revision: 64706
Erstellungsdatum: 2015-01-20
Build Platform: i686-pc-mingw32
GDAL/OGR: 1.11.2
PROJ.4: 4.8.0
GEOS: 3.4.2
SQLite: 3.7.17
Python: 2.7.4
wxPython: 2.8.12.1
Platform: Windows-7-6.1.7601-SP1 (OSGeo4W)
}}}

and

> (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

r.basin starts.

closing the ticket; reopen if needed.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1555#comment:8&gt;
GRASS GIS <http://grass.osgeo.org>

#1555: python-scripts in wingrass64svn
---------------------+--------------------------------------
  Reporter: hellik | Owner: grass-dev@…
      Type: defect | Status: closed
  Priority: normal | Milestone: 6.4.4
Component: Python | Version: 6.4.2 RCs
Resolution: fixed | Keywords: wingrass, python scripts
       CPU: x86-32 | Platform: MSWindows Vista
---------------------+--------------------------------------
Changes (by hellik):

* status: new => closed
* resolution: => fixed

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/1555#comment:9&gt;
GRASS GIS <http://grass.osgeo.org>