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