[GRASS-dev] [GRASS-user] grass-addons repository

[Hamish]

Vaclav wrote:

> Hi, I wonder what is the right way to addons to the GRASS installation
> and how then handle this in GRASS. If addons are handled by the
> packaging system there is no point to handle these addons by
> g.extension (this is how it works now if I understood correctly).
> However, in this case addons are not listed in the Addons entry in the
> Module tree in the Search modules tab in layer manager, since
> currently only modules available during compilation (using generated
> XML) and modules in .grass7/addons (using g.extension -a) are added to
> this tree.

for a grass-addon package from e.g. the UbuntuGIS ppa, I'd suggest to
treat them as a "distribution toolbox" and so as any other new toolbox.
Then leave it up to the user to avoid re-downloading with g.extension.py.
I don't see much point in trying to maintain them in a addon xml registry;
or rather I still have a hard time understanding how such a registry
deals with the theoretical 50% of addon modules which are personal
scripts authored by the user and not in the grass repository. And
following that line of thought how a time-frozen selection of addon
modules from a PPA should co-exist with both user scripts and "live"
&/or updated addon modules direct from svn. Given all that grey area
the best I can suggest is to stay as flexible as possible, and so my
concern with the xml registry is that it can be quite brittle and so
fragile. :-/  but really I have no better idea to suggest. the self-
assembling freedesktop.org *.desktop menus + icon files used by Gnome/
KDE/Xfce/LXDE is one way to do it, but having worked with that a bit
making the custom menus for the osgeo live disc, I'd observe that it
works, but their way is rather abstruse and not very enjoyable to code.

You might also explore how GEM + gis.m organized this in GRASS 6 for
some ideas.

where does the ubuntu recipe install them on the disk now?


I am sure it is possible, somehow.. :)


regards,
Hamish