Spack: Difference between revisions
Line 1: | Line 1: | ||
==Introduction== | ==Introduction== | ||
Spack is a | Spack is a software package setup and build system. It can replace [[UPS]], MRB (Multi-Repo Build) and [[Muse]] "package managers". Spack was developed for the supercomputer environment and is common use there today. The driving force that inspired spack is the need to install many packages while coordinating their dependencies. | ||
The computing division will provide their software (art, ifdhc) within the spack framework. They have requested that we adopt spack as far as possible, so that the lab can converge to one package manager which will simplify maintenance and support. It will also prepare us to be more efficient in our use of supercomputers in the future. The lab has decided to end support for UPS and only provide software in the spack framework starting with he adoption of the AlmaLinux operating system, which will fully adopted by the hard deadline of 6/30/2024. | |||
spack is designed to manage your code from github repo, to build, to installation in the final location. However, for a few reasons, we are adopting spack in two phases. For historical reasons, they are phase 2 and 3. In phase 2, we build our Offline repos locally driven by the muse scripts and link to the art suite libraries which are delivered in spack format. This has the primary advantage that all muse commands and functionality same the same. | |||
Phase 3, which is full spack adoption, we expect will come in two forms. The first is "bare spack" for experts who are comfortable working with spack directly, and a "wrapped' version with Muse-like script which will hide most details for beginners and casual code users. A basic build in bare spack is being used in [[Cmake DAQ]]. | |||
==Usage== | ==Usage== |
Revision as of 03:49, 26 April 2024
Introduction
Spack is a software package setup and build system. It can replace UPS, MRB (Multi-Repo Build) and Muse "package managers". Spack was developed for the supercomputer environment and is common use there today. The driving force that inspired spack is the need to install many packages while coordinating their dependencies.
The computing division will provide their software (art, ifdhc) within the spack framework. They have requested that we adopt spack as far as possible, so that the lab can converge to one package manager which will simplify maintenance and support. It will also prepare us to be more efficient in our use of supercomputers in the future. The lab has decided to end support for UPS and only provide software in the spack framework starting with he adoption of the AlmaLinux operating system, which will fully adopted by the hard deadline of 6/30/2024.
spack is designed to manage your code from github repo, to build, to installation in the final location. However, for a few reasons, we are adopting spack in two phases. For historical reasons, they are phase 2 and 3. In phase 2, we build our Offline repos locally driven by the muse scripts and link to the art suite libraries which are delivered in spack format. This has the primary advantage that all muse commands and functionality same the same.
Phase 3, which is full spack adoption, we expect will come in two forms. The first is "bare spack" for experts who are comfortable working with spack directly, and a "wrapped' version with Muse-like script which will hide most details for beginners and casual code users. A basic build in bare spack is being used in Cmake DAQ.
Usage
setup mu2e source /cvmfs/fermilab.opensciencegrid.org/packages/common/spack/rollout/NULL/share/spack/setup-env.sh
defines
SPACK_ROOT=/cvmfs/fermilab.opensciencegrid.org/packages/common/spack/rollout/NULL MODULEPATH=$SPACK_ROOT/share/spack/modules/linux-scientific7-x86_64 DK_NODE=$SPACK_ROOT/share/spack/dotkit/linux-scientific7-x86_64 PATH= ... /cvmfs/fermilab.opensciencegrid.org/packages/common/spack/rollout/NULL/bin BASH_FUNC_spack()=... load ... unload ...
and some useful commands
spack -h spack find -h spack arch spack find spack find --variants art_root_io arch=linux-scientific7-x86_64_v2 %gcc@13.1.0 spack find -ldv
You can see the common lab packages are available in spack: ifdhc, jobsub_client, sam_web_client.
spack load ifdhc # load (like ups setup) using a hash for the version and qualifiers spack load ifdhc/242t7pk
Notes
show what spack knows about architectures
spack arch --known-targets
full listing of dependencies
spack find --long --show-flags --deps --variants ifdhc
diff between two hashes
spack diff art-root-io/jrcjyn4 art-root-io/h43e5rd
How to group sets of setups into one. You can make a spack environment, like
spack env create uboone_analysis_current_sl7_x86_64
then
spack activate uboone_analysis_current_sl7_x86_64
and "spack install" packages into it; then if you
spack env activate uboone_analysis_current_sl7_x86_64
those will be the packages you see, and they're all spack loaded at once. Marc stills need to add support for that to the cvmfs scripts though...
geant names
geant data packages have different names in spack. From Julia:
g4able is G4ABLA g4emlow is G4EMLOW g4neutron is G4NDL g4nucleonsxs is G4SAIDDATA g4nuclide is G4ENSDFSTATE g4photon is PhotonEvaporation g4pii is G4PII g4radiative is RadioactiveDecay g4tendl is G4TENDL g4particlexs is G4PARTICLEXS g4incl is G4INCL G4NEUTRONXS appears to be obsolete.
References
- lab intro talk
- spack official docs
- public packages
- lab spack wiki and tutorial
- githubs
- FNALssi (spack, spack tools)
- fermitools (metacat, jobsub, POMS)
- art framework
- artdaq
- recipe repos
- mu2e-spack (ots,mdh)
- fnal_art (art,canvas,ifdhc)
- artdaq
- scd_recipes (metacat)
- builtin lab spack
- cetmodules
- cmake
- gfal2