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? _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
