[Rivet] installation

[Andy Buckley]

On 27/01/14 00:18, Frank Siegert wrote:
> Hi Andy,
> 
> I'm not sure that many experiment users necessarily install their own
> copy of Rivet, in particular not if they have access to LCG. So even
> with limited manpower, and to make any effort on Rivet have the impact
> we want it to have, we should avoid locking a large part of our
> userbase out. We didn't do so badly for that before Rivet2, i.e. with
> easier dependencies and the old bootstrap script, except that it being
> in Python wasn't very smart for maintainability. So back to
> constructiveness:

A bit off-topic, but I think it's important for how we handle the
bootstrap scripts to appreciate that the Python wasn't the problem. The
bootstrap _used_ to be a shell script, which became equally
unmaintainable due to feature creep from the initial intention. It was
rewritten in Python to make it sane, which felt great for a while, then
feature creep happened again. The answer was not so much the choice to
go back to shell scripting (which is a pain for conditionals, string
parsing, etc.) but to go right back to basics and explicitly not try to
handle more than one "configuration" per script. It was intended to be
sufficiently simple that no-one would be intimidated away from
cutomising it as required for their own system.

So we have to make sure that we don't have to rewrite this *again* in 2
years... it's not the physics code and I know what I'd rather spend
limited time supporting and developing. The main threat now is that we
make so many overlapping scripts for different situations that any
change needs to be applied 10 times or they all get out of sync and it's
chaos.

> I'm attaching a proposal for a rivet-2-bootstrap script. It's not
> trying to be smart about what is already installed, but simply
> installs everything by default, unless the user specifies that
> something already exists (and if necessary, in which directory). For
> example:
> 
>   INSTALL_BOOST=0 BOOSTPATH=/usr/local ./rivet-2-bootstrap
> 
> I'm still running a test for the RIVETDEV installation option, so
> don't consider it completely working and final yet. But if the basic
> idea looks Ok to you, I'd put this into the repository as
> rivet-2-bootstrap, and move the current one to
> rivet-2-bootstrap-lcg(?).

Yes, fine!

> Or would you rather have both in one with
> automatic switching if /afs is available or not?

No, I really don't want to go back to any automatic switching. And I'm
actually quite dubious about the RIVETDEV mode: it adds more
dependencies and switching logic, i.e. exactly one of the things that
screwed us in the first place. So I would rather have that as a separate
script... and maybe available from a different place and flagged as not
intended to be robust for public use.

HEP systems are so screwed up that I expected (based on my own reaction)
that most developers will either not use them at all for development, or
will anyway have to make a customised script for their own
pain-in-the-ass system. Proliferating a whole bunch of
rivet2-bootstrap-slac, rivet2-bootstrap-ippp-dev,
rivet2-bootstrap-cern-lcg-dev, ... variations would be nuts. But it
seems my way of working isn't representative, so I'm more than happy for
someone else to take over this bit!

Andy


> On 26 January 2014 23:59, Andy Buckley <andy.buckley at cern.ch> wrote:
>> Hi Franks,
>>
>> Well, it's usable in proportion to the amount of developer time that we
>> have had to spend on making it nice... the main users what we have had
>> to win over are the experiment ones who access it through experiment
>> frameworks or from the Genser-built copy. So certainly that's who I've
>> been aiming my limited build system dev time at, and to be honest I
>> still stand by that choice although I'd rather not have *anyone* annoyed
>> by our code.
>>
>> For a tarball build I think the dependencies are as follows:
>>
>> YODA requires:
>>  * Boost (headers only, but currently asks for quite a new version...
>> can maybe be relaxed: any testers?)
>>
>> Rivet requires:
>>  * HepMC, FastJet (unavoidable, I think)
>>  * YODA (yes, could have been built-in, but it has wider utility)
>>  * yaml-cpp (for 2.1.0 I'd like to use a built-in copy, cf. the latest
>> LHAPDF6)
>>  * GNU Scientific Library (volunteers to eliminate that dependency? But
>> is typically an easily-met requirement, I think)
>>  * Boost (headers only, fairly easy version requirement, I think)
>>
>> If we eliminate yaml-cpp, how much is there to object to? Anyway, yes
>> Frank I'd be very happy for you to make a new rivet2-bootstrap script
>> which builds everything from scratch... and/or attempts to work out what
>> is already on the system? At some level users should make their own
>> minds up about what to install from packaging systems and what by
>> hand... but by saying that I probably give away what side of Frank's
>> nerd fence I'm sitting on ;-)
>>
>> Anyway, in short I don't see so much room for cutting things down, but
>> always think that smoothing the entry paths (with scripts or otherwise)
>> is a good thing as long as it's kept manageable for the developers, too.
>> Since that's translated as "next to no manpower" for the last... two
>> years?, I'm afraid the situation isn't so surprising. But we'll do what
>> we can -- certainly I want to get rid of the yaml-cpp explicity
>> requirement, and hopefully we can get a couple of new part-time
>> developers (re)activated in the coming months.
>>
>> Andy
>>
>>
>> On 26/01/14 19:47, Frank Siegert wrote:
>>> I hate to admit that I agree with Frank's rant here, and I have had
>>> multiple users recently who made the same point, though admittedly
>>> more politely. The bootstrap script currently is close to useless to
>>> everybody who isn't installing on lxplus. I have it on my agenda to
>>> replace it with a working version, but haven't got around to it yet.
>>> And to be honest, all the changes and external dependencies that came
>>> with Rivet2 have left me as a second-class developer (if even),
>>> because there is a lot of stuff in the codebase which is beyond my
>>> capabilities to fix -- I'm normally quite annoyed myself with even
>>> installing Rivet on a new cluster, where
>>> cython/yaml/yoda/boost/cmake/hg/fastjet/hepmc... isn't available. Some
>>> of those are only necessary for the development version, but it's
>>> still rather annoying.
>>> This goes far beyond the switch to YODA, which I agree with as
>>> necessary, though tbh I originally thought would be Rivet-in-house as
>>> well.
>>>
>>> Anyway, as I'm clearly not the majority of Rivet developers, and
>>> mostly everybody else on the team seems to be happy about this usage
>>> of fancy new technologies, separation and dependencies, there is no
>>> point in discussing that in itself. But we definitely need a usable
>>> bootstrap script much more urgently than we needed it for Rivet1.
>>>
>>> Andy, what about renaming the current rivet2 bootstrap script to
>>> rivet-2-bootstrap-lcg, and (me) creating a separate one which actually
>>> does all the installations on its own (but without support for Rivet1
>>> of course, to avoid it becoming too bloated as the old one did)?
>>>
>>> Cheers,
>>> Frank
>>>
>>>
>>> On 26 January 2014 17:13, Frank Krauss <frank.krauss at durham.ac.uk> wrote:
>>>> Dear Rivet Authors,
>>>> I am just towards the end of my second hour running trying to install Rivet 2.0.  Admittedly, I am not half as geeky and nerdy as you are, so I accepted/anticipated that this would take me an hour.  But, please, can you explain the rationale why you use
>>>> cython, yaml, yoda, boost, fastjet & hepmc (I am sure i missed some!)
>>>> in a non-trivial way with non-trivial version specifications without providing a meaningful installation guide?  You certainly do not want the common people to use your code - is that it?  If you think this helps the user base you are mightily mistaken.  If you think I will continue to advertise your code, you're delusional - this is next to uninstallable as it stands now, with a pretty superficial installation help.
>>>> Best wishes
>>>>     Frank
>>>>


-- 
Dr Andy Buckley, Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow / PH Dept, CERN