g.extension.add available to install GRASS Addons SVN modules (GEM replacement)

[Markus Neteler]

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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Martin Landa]

Hi,

2009/7/5 Markus Neteler <[hidden email]>:

[...]

> 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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Martin Landa]

2009/7/5 Martin Landa <[hidden email]>:

typo in url...

> [2] https://svn.osgeo.org/grass/grass-addons/grass7/general/g.extension.add/g.extension.add

https://svn.osgeo.org/grass/grass-addons/grass7/general/g.extension.add/

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Markus Neteler]

On Sun, Jul 5, 2009 at 5:30 PM, Martin Landa<[hidden email]> wrote:
> 2009/7/5 Markus Neteler <[hidden email]>:
>
> [...]
>
>> 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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Moritz Lennert]

On Sun, July 5, 2009 17:30, Martin Landa wrote:

> Hi,
>
> 2009/7/5 Markus Neteler <[hidden email]>:
>
> [...]
>
>> 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

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Martin Landa]

Hi,

2009/7/5 Moritz Lennert <[hidden email]>:

[...]

> 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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Markus Neteler]

On Sun, Jul 5, 2009 at 7:17 PM, Moritz
Lennert<[hidden email]> wrote:

> On Sun, July 5, 2009 17:30, Martin Landa wrote:
>> Hi,
>>
>> 2009/7/5 Markus Neteler <[hidden email]>:
>>
>> [...]
>>
>>> 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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Martin Landa]

Hi,

2009/7/5 Markus Neteler <[hidden email]>:

[...]

>> 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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[William Kyngesburye]

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 <[hidden email]>:
>>
>> [...]
>>
>>> 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


_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Markus Neteler]

On Sun, Jul 5, 2009 at 7:55 PM, Martin Landa<[hidden email]> wrote:

> Hi,
>
> 2009/7/5 Markus Neteler <[hidden email]>:
>
> [...]
>
>>> 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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Martin Landa]

Hi,

2009/7/5 William Kyngesburye <[hidden email]>:

[...]

> 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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Martin Landa]

Hi,

2009/7/5 Markus Neteler <[hidden email]>:

[...]

> 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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Glynn Clements]

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 <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[hamish-2]

Glynn wrote:
> Installing extensions via the GUI should install them for
> an individual user, not system-wide.

perhaps default to ~/.grass/addons/ ?

(together with rename of .grassrc7 in trunk (it's not a rc file).
call that ~/.grass/init ? or?)


Hamish



     

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[William Kyngesburye]

On Jul 5, 2009, at 10:43 PM, Hamish wrote:

> Glynn wrote:
>> Installing extensions via the GUI should install them for
>> an individual user, not system-wide.
>
> perhaps default to ~/.grass/addons/ ?
>
> (together with rename of .grassrc7 in trunk (it's not a rc file).
> call that ~/.grass/init ? or?)
>

I was thinking about suggesting something like this, to mirror what I  
did for the OSX application build.  To make it easily user-
configurable, similar to other path settings, how about a GRASS env  
variable?  This would make it easier to tailor it to OS conventions.  
I think this was briefly discussed once, but I don't remember what the  
suggestions were.

Currently for GRASS 7 I have the OSX user path as ~/Library/
Application Support/GRASS/{version}/Modules.  The version is the  
version used in the GRASS install dir name.

(For GRASS 6 I skipped the 'Application Support' subdir)  The OSX  
startup just adds the .../bin dir to GRASS_ADDON_PATH.

Also, it should support multiple prefixes.  Then there could be a user  
path, and a global path that an admin could add to without touching  
the GRASS base application ("bad thing" to do on OSX).

Note that (if it wasn't obvious) this dir should have the full  
complement of bin/lib/etc subdirs, since a module could have its own  
library and/or support files.  And I added a GRASS_ADDON_ETC variable  
and g_find_etc to handle this, for modules that need to locate their  
support files.

On a side note, it would be nice to have built-in modules check with  
find_etc, so a user could add, say, color rule files that could be  
used in r.colors.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"I ache, therefore I am.  Or in my case - I am, therefore I ache."

- Marvin


_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Martin Landa]

Hi,

2009/7/6 Hamish <[hidden email]>:
> perhaps default to ~/.grass/addons/ ?
>
> (together with rename of .grassrc7 in trunk (it's not a rc file).
> call that ~/.grass/init ? or?)

I like the idea of `.grass` directory. There is also .grasswx7 which
could be moved to `.grass/wx`.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Martin Landa]

Hi,

2009/7/6 Hamish <[hidden email]>:
> perhaps default to ~/.grass/addons/ ?

done in r38399.

BTW, is it possible to install separate module? Rule for 'install'
seems to be missing.

make MODULE_TOPDIR=path INST_DIR=path install

make: *** No rule to make target `install'.  Stop.

Thanks in advance, Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[William Kyngesburye]

On Jul 13, 2009, at 12:07 PM, Martin Landa wrote:

> Hi,
>
> 2009/7/6 Hamish <[hidden email]>:
>> perhaps default to ~/.grass/addons/ ?
>
> done in r38399.
>
Shouldn't the default be a configurable path?  I'm thinking something  
that would point to the .grass folder, especially if we start using it  
for preferences and configuration info.  Maybe GRASS_USER, or someone  
has a better suggestion?

This will let platform-specific startups set this and the user doesn't  
have to figure out where it is to specify it when installing an addon.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

Theory of the Universe

There is a theory which states that if ever anyone discovers exactly  
what the universe is for and why it is here, it will instantly  
disappear and be replaced by something even more bizarrely  
inexplicable.  There is another theory which states that this has  
already happened.

-Hitchhiker's Guide to the Galaxy 2nd season intro


_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[Markus Neteler]

On Mon, Jul 6, 2009 at 12:11 AM, Glynn Clements<[hidden email]> 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
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev

[William Kyngesburye]

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


_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev