Hi,
I have written a simple script to replace GEM:
Example: install i.landsat.toar from GRASS Addons SVN:
g.extension.add extension=i.landsat.toar
Or r.terracost (the lazy user may omit even extension=):
g.extension.add r.terracost
It will download, compile and install the requested module.
It can also be used to fetch a later update of course.
The script itself is yet in Addons [1]. It requires 6.4.0RC5 or 6.5.
It won't work with GRASS 7 since the "make install" support wasn't
yet implemented (see my other mail).
Feel free to improve/rewrite the module directly in SVN (ideally
rewrite it to Python).
Cheers
Markus
[1] https://svn.osgeo.org/grass/grass-addons/general/g.extension.add/g.extension.add
Hi,
2009/7/5 Markus Neteler <neteler@osgeo.org>:
[...]
Feel free to improve/rewrite the module directly in SVN (ideally
rewrite it to Python).
done [2], untested. I would vote for moving this module to trunk and
integrate it into wxGUI. Probably it's less robust solution comparing
to GEM, anyway it's easier to maintain.
[2] https://svn.osgeo.org/grass/grass-addons/grass7/general/g.extension.add/g.extension.add
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
On Sun, Jul 5, 2009 at 5:30 PM, Martin Landa<landa.martin@gmail.com> wrote:
2009/7/5 Markus Neteler <neteler@osgeo.org>:
[...]
Feel free to improve/rewrite the module directly in SVN (ideally
rewrite it to Python).
done [2], untested.
wow cool!
I would vote for moving this module to trunk and
integrate it into wxGUI. Probably it's less robust solution comparing
to GEM, anyway it's easier to maintain.
yes & yes.
Markus
On Sun, July 5, 2009 17:30, Martin Landa wrote:
Hi,
2009/7/5 Markus Neteler <neteler@osgeo.org>:
[...]
Feel free to improve/rewrite the module directly in SVN (ideally
rewrite it to Python).
done [2], untested. I would vote for moving this module to trunk and
integrate it into wxGUI. Probably it's less robust solution comparing
to GEM, anyway it's easier to maintain.
But it seems Linux-centric (e.g. "sudo"), so I'm not sure that this is a
good idea to integrate into the GUI, now that we are trying to be as
platform-independent as possible.
Moritz
Hi,
2009/7/5 Moritz Lennert <mlennert@club.worldonline.be>:
[...]
But it seems Linux-centric (e.g. "sudo"), so I'm not sure that this is a
good idea to integrate into the GUI, now that we are trying to be as
platform-independent as possible.
Right, anyway I think that integration to GRASS 7 is first step to
rewrite the module (i.e. evolution) to be platform independent.
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
On Sun, Jul 5, 2009 at 7:17 PM, Moritz
Lennert<mlennert@club.worldonline.be> wrote:
On Sun, July 5, 2009 17:30, Martin Landa wrote:
Hi,
2009/7/5 Markus Neteler <neteler@osgeo.org>:
[...]
Feel free to improve/rewrite the module directly in SVN (ideally
rewrite it to Python).
done [2], untested. I would vote for moving this module to trunk and
integrate it into wxGUI. Probably it's less robust solution comparing
to GEM, anyway it's easier to maintain.
But it seems Linux-centric (e.g. "sudo"), so I'm not sure that this is a
good idea to integrate into the GUI, now that we are trying to be as
platform-independent as possible.
Sure - but please ask precisely what's missing. Fails on Mac?
What's needed on Windows? More conditions can be added.
Certainly the python version is more suitable to be updated, my
shell script is a proof of concept.
Markus
Hi,
2009/7/5 Markus Neteler <neteler@osgeo.org>:
[...]
I would vote for moving this module to trunk and
integrate it into wxGUI. Probably it's less robust solution comparing
to GEM, anyway it's easier to maintain.
then I would suggest to rename module to 'g.extension' for
adding/removing/updating selected extension. Make sense to you?
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
On Jul 5, 2009, at 12:17 PM, Moritz Lennert wrote:
On Sun, July 5, 2009 17:30, Martin Landa wrote:
Hi,
2009/7/5 Markus Neteler <neteler@osgeo.org>:
[...]
Feel free to improve/rewrite the module directly in SVN (ideally
rewrite it to Python).
done [2], untested. I would vote for moving this module to trunk and
integrate it into wxGUI. Probably it's less robust solution comparing
to GEM, anyway it's easier to maintain.
But it seems Linux-centric (e.g. "sudo"), so I'm not sure that this is a
good idea to integrate into the GUI, now that we are trying to be as
platform-independent as possible.
Moritz
The OSX app has a user modules dir that wouldn't need sudo. g.extension.add should support at least support an arbitrary install location. Maybe: prefix=
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
"Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life."
- Marvin
On Sun, Jul 5, 2009 at 7:55 PM, Martin Landa<landa.martin@gmail.com> wrote:
Hi,
2009/7/5 Markus Neteler <neteler@osgeo.org>:
[...]
I would vote for moving this module to trunk and
integrate it into wxGUI. Probably it's less robust solution comparing
to GEM, anyway it's easier to maintain.
then I would suggest to rename module to 'g.extension' for
adding/removing/updating selected extension. Make sense to you?
Sure!
BTW: I tried the python version but got two errors:
make MODULE_TOPDIR=/home/neteler/grass65
make: *** No rule to make target `g.extension.add', needed by
`/home/neteler/grass65/dist.x86_64-unknown-linux-gnu/scripts/g.extension.add'.
Stop.
(that happens because the script's name is g.extension.add.py)
I just added a link locally
ln -s g.extension.add.py g.extension.add
but obviously a change in
include/Make/Script.make
is desired.
g.extension.add i.landsat.toar
...
Converting: /home/neteler/grass64/dist.x86_64-unknown-linux-gnu/docs/html/i.landsat.toar.html
to /home/neteler/grass64/dist.x86_64-unknown-linux-gnu/man/man1/i.landsat.toar.1
make[2]: Leaving directory
`/home/neteler/grassdata/spearfish60/neteler/.tmp/localhost/30236.1/i.landsat.toar'
make[1]: Leaving directory
`/home/neteler/grassdata/spearfish60/neteler/.tmp/localhost/30236.1/i.landsat.toar'
Installing 'i.landsat.toar'...
Traceback (most recent call last):
File "/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/scripts/g.extension.add",
line 161, in <module>
sys.exit(main())
File "/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/scripts/g.extension.add",
line 143, in main
'install'])
File "/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/etc/python/grass/script/core.py",
line 54, in call
return Popen(*args, **kwargs).wait()
File "/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/etc/python/grass/script/core.py",
line 48, in __init__
startupinfo, creationflags)
File "/usr/lib64/python2.6/subprocess.py", line 595, in __init__
errread, errwrite)
File "/usr/lib64/python2.6/subprocess.py", line 1106, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
No idea what's wrong here.
Markus
Hi,
2009/7/5 William Kyngesburye <woklist@kyngchaos.com>:
[...]
The OSX app has a user modules dir that wouldn't need sudo. g.extension.add
should support at least support an arbitrary install location. Maybe:
prefix=
done in r38264.
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
Hi,
2009/7/5 Markus Neteler <neteler@osgeo.org>:
[...]
Installing 'i.landsat.toar'...
Traceback (most recent call last):
File "/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/scripts/g.extension.add",
line 161, in <module>
sys.exit(main())
File "/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/scripts/g.extension.add",
line 143, in main
'install'])
File "/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/etc/python/grass/script/core.py",
line 54, in call
return Popen(*args, **kwargs).wait()
File "/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/etc/python/grass/script/core.py",
line 48, in __init__
startupinfo, creationflags)
File "/usr/lib64/python2.6/subprocess.py", line 595, in __init__
errread, errwrite)
File "/usr/lib64/python2.6/subprocess.py", line 1106, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory
No idea what's wrong here.
Hopefully fixed in r38271.
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
William Kyngesburye wrote:
>>> Feel free to improve/rewrite the module directly in SVN (ideally
>>> rewrite it to Python).
>>
>> done [2], untested. I would vote for moving this module to trunk and
>> integrate it into wxGUI. Probably it's less robust solution comparing
>> to GEM, anyway it's easier to maintain.
>
> But it seems Linux-centric (e.g. "sudo"), so I'm not sure that this
> is a
> good idea to integrate into the GUI, now that we are trying to be as
> platform-independent as possible.
The OSX app has a user modules dir that wouldn't need sudo.
g.extension.add should support at least support an arbitrary install
location. Maybe: prefix=
Installing extensions via the GUI should install them for an
individual user, not system-wide.
System-wide installations should always be done via the OS' own
package management system: RPM, apt-get, portage, etc.
This isn't something GRASS can improve upon: it's one of those
situations where "different" is inherently "worse".
--
Glynn Clements <glynn@gclements.plus.com>
On Mon, Jul 6, 2009 at 12:11 AM, Glynn Clements<glynn@gclements.plus.com> wrote:
William Kyngesburye wrote:
...
The OSX app has a user modules dir that wouldn't need sudo.
g.extension.add should support at least support an arbitrary install
location. Maybe: prefix=
Installing extensions via the GUI should install them for an
individual user, not system-wide.
System-wide installations should always be done via the OS' own
package management system: RPM, apt-get, portage, etc.
Fine with that but the GRASS 7 version currently defines:
g.extension -h
prefix Prefix where to install extension
default: $(HOME)/.grass/addons
I guess that this is an oversight and should be
default: $(HOME)/.grass7/addons
?
Additionally: to fully make sense, shouldn't this directory be the default
value for the variable
GRASS_ADDON_PATH
in
lib/init/functions.sh
lib/init/grass.py
lib/init/init.bat
?
Markus
On Jul 30, 2009, at 2:59 PM, Markus Neteler wrote:
Fine with that but the GRASS 7 version currently defines:
g.extension -h
prefix Prefix where to install extension
default: $(HOME)/.grass/addons
I guess that this is an oversight and should be
default: $(HOME)/.grass7/addons
?
Additionally: to fully make sense, shouldn't this directory be the default
value for the variable
GRASS_ADDON_PATH
GRASS_ADDON_PATH is to a bin folder, and can be multiple paths. The prefix for extension installation should be a single path to a standard bin/lib/etc structured folder.
in
lib/init/functions.sh
lib/init/grass.py
lib/init/init.bat
?
-----
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
On Thu, Jul 30, 2009 at 11:07 PM, William
Kyngesburye<woklist@kyngchaos.com> wrote:
On Jul 30, 2009, at 2:59 PM, Markus Neteler wrote:
Fine with that but the GRASS 7 version currently defines:
g.extension -h
prefix Prefix where to install extension
default: $(HOME)/.grass/addons
I guess that this is an oversight and should be
default: $(HOME)/.grass7/addons
?
I'll change to $(HOME)/.grass7/addons is there are no
objections.
Additionally: to fully make sense, shouldn't this directory be the default
value for the variable
GRASS_ADDON_PATH
GRASS_ADDON_PATH is to a bin folder, and can be multiple paths. The prefix
for extension installation should be a single path to a standard bin/lib/etc
structured folder.
As emerged earlier, it should be outside of the standard GRASS installation.
My point was: if GRASS_ADDON_PATH doesn't point to the g.extension
default, the users will install an extension and then won't find it since it
is not in the path.
in
lib/init/functions.sh
lib/init/grass.py
lib/init/init.bat
?
Markus
Hi,
2009/7/30 Markus Neteler <neteler@osgeo.org>:
[...]
GRASS_ADDON_PATH is to a bin folder, and can be multiple paths. The prefix
for extension installation should be a single path to a standard bin/lib/etc
structured folder.
As emerged earlier, it should be outside of the standard GRASS installation.
My point was: if GRASS_ADDON_PATH doesn't point to the g.extension
default, the users will install an extension and then won't find it since it
is not in the path.
probably g.extension could check if given prefix is in
GRASS_ADDON_PATH and update it if needed?
Martin
--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa