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

[Frank Siegert]

Hi democrats,

Given that we decided to re-instate the old behaviour for the plotting 
case, shouldn't we do this before 1.5.0? Otherwise we'll have a change 
from 1.4.0 -> 1.5.0 and the reverse from 1.5.0 -> 2.0.0.

Cheers,
Frank

On 07/02/11 16:55, Andy Buckley wrote:
> On 07/02/11 15:08, Frank Siegert wrote:
>> 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?
>
> I am probably still living in the past -- we had some previous cases
> where this was required because of nasty hacks that needed to be applied
> for tuning, but which we couldn't put into the release. It's not a good
> argument, and it makes more sense for these weirdo requirements to be
> the ones that should be worked around :)
>
> I think there is a consensus that the "use first version found"
> behaviour would be a good one, so I withdraw all my flimsy objections. I
> think we should assign this as a development task for release 2.0.0 --
> some restructuring of the analysis loader system (damn, I thought I
> would never have to look at that again) will be needed, and I don't
> think we should delay the physics-driven version 1.5.0 to implement this
> feature. But if someone else wants to do it now, and quickly, please do so!
>
> See, Rivet design can be a democracy... when it suits me :P
>
> Andy
> ~BDFL
>