Martin: > In the result, only one variable GRASS_ADDON_BASE would be > enough, to define PATH (bin & scripts) ETC (etc) or MAN (man).
more on this below. > Your suggestion is to replace GRASS_ADDON_PATH (as used > currently in trunk) by GRASS_ADDON_BASE, right? if yes, > it make sense to me. yes, to untangle the dual definition. in case it hasn't been clear, my occasional little rants/devil's advocate adventures generally have a common thread, be it this current question of "what it means to be an addon?" or my sometimes rabid pursuit on backwards compatibility: we must not artificially hobble the user's possibilities due to our limited imagination of what can or should be possible. grass's flexibility and extendability is one of our greatest assets and needs to be jealously guarded. most user "addons" to grass we will never know. they'll be self written little (or big) scripts used to integrate grass with their local research team's workflow and model integration. a whole mix of things written in shell script, perl, fortran, R, matlab, lisp, whatever-- our job is to keep grass flexible enough for folks to take these building blocks and do neat and novel stuff with it. this is the spirit in which GRASS_ADDON_PATH was added: to add the directory(s) which housed all a user's custom scripts into the grass environment. downloadable extensions, and the framework to support them from our own little CRAN-like app store is a cool service for us to offer, but in doing so we shouldn't harm those that simply want to link to their personal scripts collection via an extended $PATH. these ideas are not in conflict: we can do both. all that it means is that on a technical level each concept will need its own descriptor, that's all. thanks, Hamish _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
