[GRASS-dev] [GRASS GIS] #2138: winGRASS6.4.svn - addon python script status?

[GRASS GIS]

#2138: winGRASS6.4.svn - addon python script status?
-------------------------------------+--------------------------------------
 Reporter:  hellik                   |       Owner:  grass-dev@…              
     Type:  defect                   |      Status:  new                      
 Priority:  blocker                  |   Milestone:  6.4.4                    
Component:  Addons                   |     Version:  svn-releasebranch64      
 Keywords:  wingrass, addon, python  |    Platform:  MSWindows 7              
      Cpu:  x86-64                   |  
-------------------------------------+--------------------------------------
Changes (by hamish):

  * version:  unspecified => svn-releasebranch64


Comment:

 see also #1768 and commit log message for r58199.

 fwiw r.threshold.py from 6.5 addons was what I've been using for a test
 case.

 r58199 is the change 2 weeks ago to g.extension.py in devbr6 which makes
 things a bit better by manually editing the wrapper .bat file to run
 %GRASS_PYTHON% instead of sh.exe. It's just a hack though, and trades
 python scripts working from the bash command line for them working in the
 wxGUI command line (on Wingrass). For Wingrass I suspect the wxGUI might
 be the more important one for the majority of users, but it makes me sad
 to choose between them, better we should make it work from everywhere.
 Since it (in part) trades one half-solution for another & I'm not happy
 with the foundation it lays, I didn't backport it yet. But I guess a
 partially working hack is better than known breakage, so it could be
 backported.

 with r58199 %GISBASE% -> %GRASS_ADDON_PATH% happens just before the SH ->
 PYTHON on line 637.

 > I'm a little bit lost in g.extension.py to change the path to
 > addons correctly also for addon python script ...

 do you need a change beyond what is in 6.5's g.extension.py?
 i.e. that a backport wouldn't solve?


 AFAIK the .py extension association on Windows is the main problem,
 getting that to work so you don't need to add the .bat extension to run
 the module, and for the second pass it knows that $0 has an assumed .py
 extension not an explicit one.


 What we really need is an include/Make/PythonScript.make, I didn't get
 very far with it beyond a minor edit to Script.make:

 {{{
 --- Script.make 2013-06-25 14:46:53.452338241 +1200
 +++ PythonScript.make   2013-06-25 14:19:50.224336291 +1200
 @@ -19,7 +19,7 @@

  $(SCRIPT): $(PGM)
         if [ ! -d $(SCRIPTDIR) ]; then $(MKDIR) $(SCRIPTDIR); fi
 -       $(INSTALL) $(PGM) $(SCRIPT)
 +       $(INSTALL) $(PGM).py $(SCRIPT)
         $(MAKE) htmlscript scriptstrings
         $(MAKE) mancmd

 }}}

 It won't solve the association problem, but it will reduce the current
 pile of hacks into a single clean place.


 To be honest, my main concern isn't reall the downloadable Python addons
 on WinGrass, since we can do a lot to fix that post-release as part of the
 nightly builds, I'm much more concerned about custom user-composed Python
 addon modules on Wingrass - that support has to be working out of the box
 - it's a really important thing to have personal Python scripts working
 for Windows users!


 regards,
 Hamish
 (still ~90% AFK these weeks)

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