[GRASS-dev] g.extension.add available to install GRASS Addons SVN modules (GEM replacement)

[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