3 ms·

I’ve tried to like this more than once, but once you hit some cryptic error somewhere in the build you’re not going to have a great time. Also unfortunately it

I’ve tried to like this more than once, but once you hit some cryptic error somewhere in the build you’re not going to have a great time. Also unfortunately it doesn’t always play nicely with lots of high energy physics software which really leans on using LD_LIBRARY_PATH and running custom executables during builds. I’ve had bad experiences with ROOT and Gaudi with no obvious paths forward for fixing things.

tgamblin 4y ago
Sorry to hear this. We have a lot of connections with the high energy physics community, which is why ROOT and Gaudi are even in Spack to begin with. There is an #hep channel on https://slack.spack.io https://slack.spack.io, and we talk to those folks fairly frequently to figure out what we can add to support these codes better. On `LD_LIBRARY_PATH` specifically: we intentionally inject RPATH-ing compiler wrappers into the build to avoid these types of problems, which are on by default for the ROOT and Gaudi builds. Would be curious to hear where the remaining pain points are.
wdconinc 4y ago
We have used spack to maintain our 1000-person user environments at the electron-ion collider (including ROOT, Gaudi) for the past two years and couldn't have done it otherwise.
prpl 4y ago
Both of those are non-trivial and annoying to say the least, I know ROOT has a few very smart people managing build recipes in conda-forge too.
gnufx 4y ago
Yes, I've found it increasingly frustrating after managing a university central HPC system with rpms. (It's a myth that you can't support different versions with rpm or dpkg if necessary.) I was at least convinced of the need for an actual package manager -- i.e. not Easybuild that everyone else favoured -- after the hell of people's environment modules installations and combinatorial explosions. For instance, several times I've had Spack in a state where it had obscure apparently internal errors that I didn't have the energy to try to diagnose, which resulted in throwing everything away and starting again. I found build recipes frequently don't actually work, especially if you're not on x86_64, though architecture accounts for a minority of the failures. You also end up quickly running out of space in ~10GB of home directory, at least if things aren't shared on the system. There is a tension between "reproducible" static configurations and the dynamics you need, e.g. to be able to link instrumentation or acceleration libraries at run time. However, there is a Spack option to use RUNPATH instead of RPATH that I'd have to look up.

tgamblin 4y ago

Sorry to hear this. We have a lot of connections with the high energy physics community, which is why ROOT and Gaudi are even in Spack to begin with. There is an #hep channel on https://slack.spack.io https://slack.spack.io, and we talk to those folks fairly frequently to figure out what we can add to support these codes better. On `LD_LIBRARY_PATH` specifically: we intentionally inject RPATH-ing compiler wrappers into the build to avoid these types of problems, which are on by default for the ROOT and Gaudi builds. Would be curious to hear where the remaining pain points are.

wdconinc 4y ago

We have used spack to maintain our 1000-person user environments at the electron-ion collider (including ROOT, Gaudi) for the past two years and couldn't have done it otherwise.

prpl 4y ago

Both of those are non-trivial and annoying to say the least, I know ROOT has a few very smart people managing build recipes in conda-forge too.

gnufx 4y ago

Yes, I've found it increasingly frustrating after managing a university central HPC system with rpms. (It's a myth that you can't support different versions with rpm or dpkg if necessary.) I was at least convinced of the need for an actual package manager -- i.e. not Easybuild that everyone else favoured -- after the hell of people's environment modules installations and combinatorial explosions. For instance, several times I've had Spack in a state where it had obscure apparently internal errors that I didn't have the energy to try to diagnose, which resulted in throwing everything away and starting again. I found build recipes frequently don't actually work, especially if you're not on x86_64, though architecture accounts for a minority of the failures. You also end up quickly running out of space in ~10GB of home directory, at least if things aren't shared on the system. There is a tension between "reproducible" static configurations and the dynamics you need, e.g. to be able to link instrumentation or acceleration libraries at run time. However, there is a Spack option to use RUNPATH instead of RPATH that I'd have to look up.