[GRASS-dev] GRASS extensions/addons mismatch

[Hamish]

Martin wrote:
> currently the GRASS AddOns extensions are installed on
> GNU/Linux to
> 
> $HOME/.grass<major_version>/addons
> 
> and on Windows to
> 
> $AppData\GRASS<major_version>\addons

(i.e. if you didn't already have GRASS_ADDON_PATH set to something
custom and you let the defaults make the choice for you)


> This layout doesn't allow to install extensions for more
> installed versions of GRASS. In other words, addons for
> GRASS 6.4.2 and GRASS 6.5 are installed on the same place

fwiw most of my personal ADDON scripts are scripts not compiled,
and I most often run into this problem when switching between grass
6 and 7 when the module parameters and flags have changed.

also I see it every now and then for trying to run new flags on older
grasses which don't have that flag yet.

for (my) scripts where grass 6/7 matters I split up $GRASS_VERSION into
majors and minors and test the major version, then if/else to have the
right thing happen automatically. (e.g. change the way I call d.mon)

for things within the same major version that want new flags, I have the
start of the script search through --interface or --xml-description and
exit with an error if the GRASS version is too old.
 e.g. see the g6/r.out.kml addon script.

I'm not proposing either of those for a formal solution as it doesn't
help compiled C modules, but fwiw that's my workaround for version-
proofing my personal scripts.


> $HOME/.grass6/addons or
> $AppData\GRASS<major_version>\addons
> 
> I would suggest to change `addons` to
> `addons<full_version>`,
> concretely GRASS 6.4.2 addons would be installed to
> 
> $HOME/.grass6/addons642 or
> $AppData\GRASS<major_version>\addons642
> 
> and GRASS 6.5 to
> 
> $HOME/.grass6/addons65 or
> $AppData\GRASS<major_version>\addons65
> 
> What do you think?

the path name gets a bit long, but for compiled code it
seems necessary and I have no better suggestion on how to
improve that or work around it.


> Other thing is that g.extension (or it's wxGUI front-end) should
> automatically ask user to update his/her extensions when you upgrade
> GRASS (libgis revision must be same for GRASS and the addons).

the classic way would be a g.extension.rebuild script, along the lines
of v.build.all or v.in.sites.all. perhaps the best solution would be
to have the GUI tick box or button or automatic popup dialog call that
generally installed script for backend processing. (so you don't need
a GUI to upgrade processing modules your headless server)

I guess the new ~/.grass6/wx[_config] file could have an entry for
'first time with this ver?' set to 0 or 1 and prompt you on startup
if it was set to 0, then scan the addons modules.xml file for candidates.
(or store x.y.z part of version string that created the ~/.grass6/wx
file IN the wx file and test against that)

switching back and forth between versions all day as I do, I can see
how clicking [no, leave me alone] 10 times a day would get annoying
very quickly.

store current version in the $addons/modules.xml file?
or maybe better within each individual xml <module> entry?
shrug

..
how well does the ~/.grass6/wx config file cope with added/removed
options if the config file is more than one or two versions out of date?
I've seen too many times to recall other C/C++ GUI apps crashing because
of that issue. It's very nice to have your preferences carry through,
but will those wx files stay forward+backward compatible for all .grass6/
and .grass7/ ?


2c,
Hamish

ps- outstanding question: should sudo/system wide installs of addons
done with g.extension.py be allowed to delete files from the main
$GISBASE base or not?