[Rivet] [Rivet-svn] r2876 - in trunk: . bin include/Rivet/Tools src/Analyses src/Core src/Tools

[Andy Buckley]

On 31/01/11 15:16, David Grellscheid wrote:
> Hi Andy,
> 
>> That was on purpose, since all of our other variables are taken as
>> canonical search path definitions
> 
> I'd like to agree with Frank. The env variable behaviour of Rivet is
> quite counterintuitive at the moment (for all of the variables).
> 
> The standard search behaviour I would expect from other tools is that
> the package that will be used comes from the first successful match in
> the following paths:
> 
>  1) contents of SOME_ENV_VARIABLE if it is set
>  2) current working directory
>  3) .foorc in user home directory
>  4) builtin global search paths
> 
> Other than Rivet, I can't recall a tool where the env variable
> completely overrides the builtin path. The builtin always gets pushed
> back in the search queue, but doesn't get removed.

That's what we used to do and it always caused problems because of cases
where you wanted an analysis with the same name as an existing one, but
a different behaviour of some kind. We could change the search behaviour
(again!) to use that "use first match found" idiom but a) that would
require restructuring the analysis loader machinery again, and b) it
would make it easily possible to run the wrong version of an analysis
just because of search path ordering or similar errors. This was exactly
why Hendrik and I chose to move to the current behaviour -- no
unexpected fallbacks or side-effects.

So, certainly, for loading actual analysis libraries I prefer the
explicit "one match or fail" behaviour, and to get that we need to be
able to override the defaults. I think the same argument applies to the
searches for ref data, plotting details, etc.... or at least I don't see
a compelling reason to be inconsistent in how they are used. The recent
changes, with fallback to the analysis search path, have been intended
to keep the override behaviour while requiring much less variable
setting: RIVET_ANALYSIS_PATH should now be usable for all path searching
purposes for 99% of uses... but I am of course biased in that view ;)

Re. .rc files: no way! Besides adding more parsers, it would just be one
more thing to have to check when users report usage problems. For tools
with a lot of uses, where there are lots of different usage idioms (e.g.
emacs, bash), .rc files are great... for Rivet I think it'll make our
lives much easier if it behaves the same on every system!

Thanks, and as usual, please try to persuade me that it should
definitely be changed, and I'll keep trying to rid myself of developer
tunnel vision ;)

Andy

-- 
Dr Andy Buckley
SUPA Advanced Research Fellow
Particle Physics Experiment Group, University of Edinburgh

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.