I just updated and compiled GRASS 7. I got an error on compiling v.krige. It looks like from the error that v.krige is looking for Python 2.6. I compiled purposefully with Python 2.5 (2.5.4 is native on GRASS OS X 10.6).
No need to rush this fix before Christmas, of course, but it will be nice to see the new v.krige. Does it really require Python 2.6 or is requirement in error?
Michael
I don't see a python version requirement in v.krige.
I think the problem is that all modules are run during compilation to generate the help file. But v.krige (like all other python scripts) has that #!/usr/bin/python in it, which then runs the default python 2.6, AND in 64bit mode so it fails to load the 32bit-only wxpython.
During compilation, it doesn't know where to find the python wrapper I created to take care of the 64bit/pythonw problem (which would also have the python version taken care of for you). (http://trac.osgeo.org/grass/ticket/841)
I'll see if I can work something out on the OSX side. Though as Glynn pointed out in that bug report, scripts should probably not be using wxpython directly (a module processes data and exits), or such scripts should not be in the scripts folder but on their own (maybe as a GUI module?).
On Dec 24, 2009, at 6:05 PM, Michael Barton wrote:
I just updated and compiled GRASS 7. I got an error on compiling v.krige. It looks like from the error that v.krige is looking for Python 2.6. I compiled purposefully with Python 2.5 (2.5.4 is native on GRASS OS X 10.6).
No need to rush this fix before Christmas, of course, but it will be nice to see the new v.krige. Does it really require Python 2.6 or is requirement in error?
Michael
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
"This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?"
- The Ruler of the Universe
William Kyngesburye wrote:
I think the problem is that all modules are run during compilation to
generate the help file. But v.krige (like all other python scripts) has
that #!/usr/bin/python in it, which then runs the default python 2.6,
AND in 64bit mode so it fails to load the 32bit-only wxpython.
It's actually "#!/usr/bin/env python", but the result is likely to be
the same.
During compilation, it doesn't know where to find the python wrapper I
created to take care of the 64bit/pythonw problem (which would also have
the python version taken care of for you).
(http://trac.osgeo.org/grass/ticket/841)I'll see if I can work something out on the OSX side. Though as Glynn
pointed out in that bug report, scripts should probably not be using
wxpython directly (a module processes data and exits), or such scripts
should not be in the scripts folder but on their own (maybe as a GUI
module?).
I think that v.krige should be split into a simple front-end script
which doesn't "import wx", and an application. The front-end script
would invoke the main script via $GRASS_PYTHON once grass.parser()
returns (*if* it returns, which it doesn't for --help etc).
--
Glynn Clements <glynn@gclements.plus.com>
On Fri, 2009-12-25 at 06:12 +0000, Glynn Clements wrote:
William Kyngesburye wrote:
I think that v.krige should be split into a simple front-end script
which doesn't "import wx", and an application. The front-end script
would invoke the main script via $GRASS_PYTHON once grass.parser()
returns (*if* it returns, which it doesn't for --help etc).
I'll look at this with Martin, thanks for feedback and tips on v.krige.
Merry Christmas to all GRASS devs 
Anne
> I think the problem is that all modules are run during compilation to
> generate the help file. But v.krige (like all other python scripts) has
> that #!/usr/bin/python in it, which then runs the default python 2.6,
> AND in 64bit mode so it fails to load the 32bit-only wxpython.
That isn't the only issue. Even if it uses the correct version of
Python, it still won't run because it imports modules from wxGUI
(globalvar, gselect, goutput, menuform), but the "scripts" directory
is built before the "gui" directory.
I think that v.krige should be split into a simple front-end script
which doesn't "import wx", and an application. The front-end script
would invoke the main script via $GRASS_PYTHON once grass.parser()
returns (*if* it returns, which it doesn't for --help etc).
That would work. But I'd suggest putting the wxPython+wxGUI portion in
the "gui" directory and installing it to $GISBASE/etc/wxpython. The
front-end could go into either "gui" or "scripts", and be installed
into $GISBASE/scripts.
--
Glynn Clements <glynn@gclements.plus.com>
Hi,
2009/12/27 Glynn Clements <glynn@gclements.plus.com>:
[...]
That would work. But I'd suggest putting the wxPython+wxGUI portion in
the "gui" directory and installing it to $GISBASE/etc/wxpython. The
front-end could go into either "gui" or "scripts", and be installed
into $GISBASE/scripts.
Seems reasonable to me.
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa