Replies: 7 comments 8 replies
-
It is very simple - take |
Beta Was this translation helpful? Give feedback.
-
From @sawenzel I think a constructive way forward would be to come to the relevant meetings (computing board, WP3 meeting) where the software packaging approach is discussed and present your (and the anonymous+) worries. This would be way better than ranting about them on the Github platform as side-remarks. In the end, choices about these systems were taken by our organisation some time ago and most people do not have problems following these common workflows (even in disagreement) because standardized approaches are a core foundation of working together efficiently. |
Beta Was this translation helpful? Give feedback.
-
A few pointers which might solve some of the issues you have. Notice how in general the documentation is at http://alisw.github.io/alibuild.
What system are you using? |
Beta Was this translation helpful? Give feedback.
-
Hi all, Let me expand upon why I dislike
There are actually ways of dealing with most of the above, but it requires a lot of discipline and some hacking. For example, an ALICE pathed library should have a distinct so-name so that it will not be loaded as a substitute for the real thing. Of course, that does not prevent an application to load both sets of libraries with possible conflicts arising. Another, and far better solution, would be to package up the software for distros. A third solution would be to run in So for me, the most effective way of setting up an environment, is to roll-my-own. What I typically do is have something like
and where Guilio asks which system I use: Debian GNU/Linux "sid" unstable - and there's another thing with using system packages - As for IDE's - there's one for any one serious about it: Emacs 😄 I case you cannot tell - I'm joking. Wrt to "development" packages - Guilio says, you mainly build them yourself. In that sense, you can say what I'm doing is treating all packages "development" packages 😄 And in some sense, that is true. I will often make patches (and submit them upstream) to third-party packages - viz, this patch for Apache Federico Carminatti initially made a very sensible decision way-back-when - to base everything on ROOT. It served as the abstraction layer that made it much easier to ensure consistency across platforms and software packages. It wasn't without its own problems, but you always had a well-defined environment - ROOT - to build on. ALICE now uses a plethora of platforms, and layers, which makes the whole thing a lot more complex: 1-to-N relations scale, M-to-N quickly becomes chaos. My 2¢ Yours, Christian |
Beta Was this translation helpful? Give feedback.
-
Again, I suspect you are lacking doing some
Sorry, this I do not buy. aliBuild is all about being able to have several installations running at the same time, reusing as much as possible of what can be reused. There is options to support multiple
Agreed, but this is outside our control. The trick is to make sure that you use modules only via top-level packages (like O2Physics, or O2PDPSuite) and not try to load stuff one by one. Anything else, with or without modules, is deemed to fail (including what you propose with the system packages, BTW) unless there is a strict policy in what goes into the release. We had at some point some discussions about "streams" (kinda like Debian releases) but it went nowhere. Maybe we should resurrect the discussion.
You answered to yourself about why that is a bad idea. I have seen that fail miserably 20 years ago. Having properly so-named stuff only works for very specific libraries and it's a mess to maintain.
What you propose would result in only the production architectures being realistically supported (i.e. no debian), and it will never be accepted by the Grid sites (which support 100% CVMFS). Moreover, it would prevent multiple installations, which are needed again on the grid. The only place where we do what you propose (repackaging alibuild tarballs into system level RPMS) is the FLP cluster where one of the top complaints is the lack of parallel installations and quick rollbacks.
Simply use the
That explains many things... :-D Have a look at the direnv integration for emacs, e.g. https://github.com/wbolster/emacs-direnv. I have never tried (I use vim's one ;-)) but it should work just as well. Hopefully the above answers to at least some of your problems.
|
Beta Was this translation helpful? Give feedback.
-
Just to add few comments:
|
Beta Was this translation helpful? Give feedback.
-
@davidrohr @pzhristov @cholmcc maybe we should take the whole discussion to an ALICE forum...
What you call "system packages" on the Grid were not present in a consistent manner, hence the need to bring our own stuff for that usecase. Nothing prevents us from using system python or openssl in general, however until very recent (in HEP terms) we had python 2.7 or openssl 0.9.8 as system baseline for our production platform. It not like we built a patched OpenSSL because of the fun of it... That said, the That said, to me the issue is not system software, apart from maybe clang, all the rest builds in a blip. The real time consuming parts are ROOT, GEANT4, the generators, and our own stack, which we will never be able to consistently distribute on all the platforms we effectively support.
Which is actually an issue with ONNX itself, which Microsoft does not seem to want to tackle. Hence the need for an obsolete flatbuffer in our stack. Again, I sympathise with the problem, but you know better than me that we have some very strict boundary condition at time... Anyway, since this is becoming a bit too "ALICE strategy" specific, I suggest we move the discussion to an ALICE forum.
Again, my answer to this would be "ALICE strategy" wrt CVMFS and not for this forum.
I have half of my 2TB empty... ;-) |
Beta Was this translation helpful? Give feedback.
-
From @cholmcc I really dislike
alidist.
It's bloated as all .... I prefer if I can install a distribution package, since I know that will work with the rest of the system. For those software packages for which there is no distribution package, I will often go to some length to see if I can make the package myself. If that becomes to cumbersome, then I will pull down the package myself and built it. That means I will often have master of a package for which ALICE uses some ancient version in alidist. Therefore, I sometimes see inconsistencies between ALICE software and third-party software that you would only discover the hard way through alidist. So there - because I can 😄Beta Was this translation helpful? Give feedback.
All reactions