[GRASS-user] AddOn or Script when compiling GRASS from source

[Hamish]

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