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

[Frank Siegert]

Hi Andy,

sorry for the late reply on this.

On 31/01/11 16:33, Andy Buckley wrote:
> On 31/01/11 15:16, David Grellscheid wrote:
>> 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.

Is that really a valid use case? If you want to write your own analysis, 
why should you be able to call it the same as an existing one?

> 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.

"Wrong version" of the stupidly named analysis from above, or is there a 
more valid use case for where that would happen?

> 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.

I agree that all Rivet path setting should be consistent. But I'd argue 
for the "first match wins" option, since I agree with David, I also 
often tend to use plugin and standard analyses at the same time.

Of course this is not related to the recent changes (fallback to 
analysis search path), these are still great and useful.

Cheers,
Frank