[GRASS-dev] Re: [GRASS GIS] #1555: python-scripts in wingrass64svn
GRASS GIS
trac at osgeo.org
Sun Jan 29 17:43:42 EST 2012
#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>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list