[GRASS-dev] GRASS extensions/addons mismatch

[Michael Barton]

There is another issue for Mac users--and this affects the overall permissions/settings files too.

All directories that begin with a "." are by default hidden from Mac users. Since permissions and settings can be accessed in other ways, this is not a big problem. 

But if we are putting addons into the same hidden directory, it is more troublesome.

William has previously put this into the /Library folder as a visible folder. This is a much more sensible place for the Mac. So we need to treat Mac's differently from Linux, like we do Windows.

Michael
______________________________
C. Michael Barton 
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
Tempe, AZ  85287-2402
USA

voice: 	480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:          480-965-7671(SHESC), 480-727-0709 (CSDC)
www: 	http://csdc.asu.edu, http://shesc.asu.edu
		http://www.public.asu.edu/~cmbarton

On Dec 14, 2011, at 6:54 AM, grass-dev-request at lists.osgeo.org wrote:

> Date: Wed, 14 Dec 2011 05:53:16 -0800 (PST)
> From: Hamish <hamish_b at yahoo.com>
> Subject: Re: [GRASS-dev] GRASS extensions/addons mismatch
> To: GRASS developers list <grass-dev at lists.osgeo.org>,  Martin Landa
>        <landa.martin at gmail.com>
> Message-ID:
>        <1323870796.32415.YahooMailClassic at web110007.mail.gq1.yahoo.com>
> Content-Type: text/plain; charset=us-ascii
> 
> 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?