[GRASS-dev] grass 6.x g.extension install path layout simplification

[Michael Barton]

Thanks Hamish.

Michael Barton
School of Human Evolution &Social Change
Center for Social Dynamics & Complexity
Arizona State University

...Sent from my iPad

On Nov 25, 2011, at 10:40 AM, "grass-dev-request at lists.osgeo.org" <grass-dev-request at lists.osgeo.org> wrote:

> Date: Fri, 25 Nov 2011 00:28:55 -0800 (PST)
> From: Hamish <hamish_b at yahoo.com>
> Subject: Re: [GRASS-dev] grass 6.x g.extension install path layout
>        simplification
> To: Glynn Clements <glynn at gclements.plus.com>
> Cc: grass-dev at lists.osgeo.org
> Message-ID:
>        <1322209735.86807.YahooMailClassic at web110005.mail.gq1.yahoo.com>
> Content-Type: text/plain; charset=us-ascii
> 
> Hamish wrote:
>> perhaps for grass7, but 10 years worth of backwards
>> compatibility with the implementations in grass5 and
>> grass6 says otherwise for those.
> 
> 
> I think perhaps I should say something about why GRASS_ADDON_PATH
> came to be. This isn't THE history, but it is a history; you
> were there & I don't mean to be condescending or anything, just
> to explain where I'm coming from since we seem to be looking
> at this from different perspectives.
> 
> [If you are too busy to read this little story, skip down to
> the "Back to the issue at hand" paragraph below.]
> 
> 
> once upon a time if you wanted to compile a non-standard module
> obtained from elsewhere or self-written you had to copy it into
> the source tree (e.g. into raster/r.module/), or symlink it
> there, and compile with `gmake5`. it then (optionally) got
> installed into your GISBASE. and all was good until you did a
> 'make clean'. worse, if you installed a new version of GRASS and
> uninstalled the old one, you lost access to your self-compiled
> module, so it was nice to copy it somewhere outside of the
> install dir which got replaced every few months.
> so far, so obvious, and fwiw I maintain a `gmake6` alias which
> runs `make MODULE_TOPDIR=...` which is generally what I use
> instead of g.extension, but then again I've got the source code
> installed which is a special case.
> 
> --it's probably worth noting here that if the GRASS ABI changed
> you had to recompile, but the same is true for things compiled
> with g.extension today, although luckily we have the GIS_H
> version test these days.
> 
> 
> At the same time, and I'd expect much more common but _invisible
> to developers_, people were writing their own scripts to do their
> own little jobs connecting the building blocks "do one thing
> well" modules together in a similar fashion to the GUI graphical
> modeler.  For example, my ADDON_PATH is littered with dozens of
> these work related scripts (reusable macros if you prefer) and a
> few personal preference shortcuts (e.g. see d.stations in addons
> svn; it's not really a module, just a glorified alias).
> 
> mainly these are the cache of scripts to run some set of analyses
> or generate some reusable plot template. they are not modules,
> but are the personal repository of workflow scripts. That is
> not to say there are no personal modules mixed in there, far
> from it, only to say that there are both modules and user-scripts
> to consider and to accommodate.
> 
> 
> anyway, back to the story:
> So eventually with grass6 we abandoned contrib/ and the list
> of external addons maintained on the website, and started the
> grass wiki and its list of addon modules. And then as some of
> those external websites started to go 404, about the same time
> as we moved to trac svn, and the addons svn was born as a more
> permanent home. Finally some of the things in the addons svn
> matured and become rather interesting to others, and non-
> developer users had some trouble compiling them, and so
> Makefiles started to pop up in the addon module dirs,
> g.extension came to be, a bit later Makefiles were added to
> compile collections of addons, and most recently the osgeo4w
> addon collection. (as `make` is not happy to run due to spaces
> in path names, and most people will not install to
> C:\GRASS-6.4.1\)  With about 20% of all public GRASS modules
> being addons, and easier access to them, progress has been good
> and we seem to be on the right track!
> 
> 
> A small digression:
> With automatic compiles of everything with a Makefile in addons
> svn there is the conceptual conflict in addons being a module
> incubator, or is it a home for finished, release quality modules?
> A svn sandbox had been added, but I'm still not fully convinced
> that addons svn should be abandoned as a place for still-in-
> development works, and what the role of the sandbox should be.
> Mainly I think where things grow organically is a better guide
> than any planned rule, so I'll wait and see where that goes with
> an open mind.
> 
> 
> Back to the issue at hand:
> 
> I get the point about addon modules in theory being drop-in
> additions to the normal source tree, and so experiencing the
> same fate and expectations (in a relative dir sense) as an
> official module, but my main point here is that GRASS_ADDON_PATH
> over the years has been as much, if not more so, useful as a
> place to put your end-user scripts, not "modules" at all. And
> GISBASE, or a GISBASE-alike, makes no sense in the context of
> a script which is not a module.
> 
> 
> In practice mine has held both self-built modules and non-module
> grass user-scripts to varying degrees, what I object to is
> imposing refugee status on the personal work-scripts at this
> late stage in a stable 6.x release series by redefining
> GRASS_ADDON_PATH into a GRASS_ADDON_BASE.
> 
> For backwards compatibility we must keep GRASS_ADDON_PATH in
> grass6 in the $PATH, and so this is just silly, for no gain:
> 
> PATH="$PATH:$GRASS_ADDON_PATH:$GRASS_ADDON_PATH/bin:$GRASS_ADDON_PATH/scripts"
> 
> vs
> 
> PATH="$PATH:$GRASS_ADDON_PATH"
> 
> symlinks are one way to do that, but not ideal for Windows.
> (but g.extension doesn't work there anyway, so I wonder if
> in practice that actually matters?)  Anyway simply combining
> $ADDONS/bin/ and $ADDONS/scripts/ avoids the symlinks and
> makes avoids the unnecessary dir structure ta boot.
> 
> If i.pr or some advanced addon wants some other part of the
> GISBASE structure, still no problem, it still gets installed.
> Since g.manual(.sh) and the guis know nothing of GRASS_ADDON_PATH
> (yet), there is no backwards compatibility to break if we move
> $ADDONS_6/man/man1 into docs/. No code is depending on that, and
> it isn't making the man pages difficult to discover when
> exploring by hand.
> 
> Ah well, enough rambling..
> 
> 
> gobble gobble,
> Hamish
>