[HN Gopher] Spack - scientific software package manager for supe...
___________________________________________________________________
Spack - scientific software package manager for supercomputers,
Linux, and macOS
Author : telotortium
Score : 66 points
Date : 2023-03-20 19:28 UTC (3 hours ago)
(HTM) web link (spack.io)
(TXT) w3m dump (spack.io)
| sjsanc wrote:
| Not to be confused with the SWC bundler for JavaScript
| https://swc.rs/docs/configuration/bundling
| Moissanite wrote:
| I encourage anyone to follow the "install your first package"
| instructions, but pick a real scientific package like WRF or
| GROMACS. Be prepared to wait a while though...
| anon9874 wrote:
| If you do pick WRF, you can also use a binary cache, as shown
| in this workshop https://weather.hpcworkshops.com/ .
| Moissanite wrote:
| I haven't tried since the binary cache launched - but over
| the years I've attempted to use Spack following their
| "getting started" guide half a dozen times and achieved
| nothing but long waits and disappointment; part of the reason
| for recommending it was a sanity check on whether I am just
| impatient or have unreasonable expectations when it comes to
| software behaving as documented.
| ephimetheus wrote:
| 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 wrote:
| 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, 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.
| kichimi wrote:
| An unfortunate name, a la Nonce Finance and Git.
|
| https://en.m.wiktionary.org/wiki/spack
| pledg wrote:
| Git was very intentional. Nonce and this I expect were not.
| CaliforniaKarl wrote:
| I think it fits. It's like spackle, that you use on walls.
| miramba wrote:
| Interesting, the same word with the same insulting meaning is
| used in northern Germany...TIL it's in English too. Maybe a
| leftover of the british occupation after WWII. Spacken Spacko
| Spack
| Moissanite wrote:
| For Americans who don't want to click the link: "Spack" is
| basically a milder British-English version of "retard". Imagine
| how well the "Spaz programming language" would do in your
| market.
| stonogo wrote:
| I think it would probably do fine, given we have languages
| like Brainfuck, image editors named The GIMP, parallel-
| processing tools named Linda (after the star of a
| pornographic film), etc.
|
| I just don't think people are that sensitive about software
| naming.
|
| There used to be a relatively popular package called "System
| Administrator's Tool for Analyzing Networks." A friend of
| mine still has a physical copy of O'Reilly's "Protecting
| Networks With SATAN."
| kichimi wrote:
| Those names dont serve to degrade people. For me, as a
| British person, this software is basically called Retard.
|
| I'm not sensitive enough to care but some people will find
| this offensive or at least make them pause before
| suggesting its use. Some word filters will filter this out
| too.
| telotortium wrote:
| I think the lesson is that British slang doesn't count when it
| comes to potentially offensive open-source software names.
| b800h wrote:
| Have to say I was fairly surprised by this name.
|
| It's a fairly old-fashioned expression, but could well cause
| some misunderstandings.
| kichimi wrote:
| I wouldn't say that, it sees regular use even today.
| trollied wrote:
| This is definitely an international blunder. I'd say it's more
| socially acceptable in the UK to call someone a c*t than it is
| to use this word. Can safely say it'll get zero UK adoption due
| to the name. Shame.
| petepete wrote:
| And then there are those of us who deal with nonce daily. I
| wince every time I see the word, and it's really awkward if
| non-technical folks hear us talking about them.
| stonogo wrote:
| Given that it's in use at Cambridge and several other HPC
| centers around the UK, I'm going to disagree. I think most
| people are cosmopolitan enough to set aside the UK's niche
| insult community to move forward with real work. I doubt
| there's any single-syllable morpheme which doesn't translate
| to something offensive somewhere.
| evancordell wrote:
| There's a good interview with the author in an episode of The
| Manifest: https://manifest.fm/11
|
| It's been a while since I've listened, but I remember it being
| pretty interesting.
| pharmakom wrote:
| What does this offer over the usual suspects brew, linuxbrew,
| apt... ?
| stonogo wrote:
| Spack allows you to have several matrices of the same package
| installed. So, if you want to install Foobar, and you want one
| copy built with gcc and linked to openmpi, one copy with llvm
| and linked to mpich, and three copies with the Intel compiler
| and three different versions of the Intel mpi libraries,spack
| can do that for you, and help manage your environment to ensure
| you are running the stack you intend.
|
| It's primary use is in supercomputing to make various
| optimizations available to users.
| CaliforniaKarl wrote:
| The examples you listed are designed to install packages on a
| single system.
|
| Spack is designed to install packages in a network-storage path
| that can be accessed by multiple semi-heterogeneous systems
| that run the same main architecture.
| throw0101b wrote:
| Multiple versions of the same package can be handy: e.g.,
| Python 3.6, 3.8. and 3.10 all handled by the package manager
| and able to switch between them on a per-session/terminal basis
| (no need to completely disable a particular install: just
| adjust $PATH and $LIB as needed).
|
| Able to create pyenv-like environments which can then be
| 'exported' and sent to other systems/users having Spack so that
| development/debugging can be done with the same setup:
|
| * https://spack-
| tutorial.readthedocs.io/en/latest/tutorial_env...
|
| Able to use 'internal' packages (spack install openssl) or
| external packages (link against /usr/lib/libssl.so) on a per
| item basis: sometimes you want the newest code, but other times
| you want the OS package so that you can get security updates
| 'for free'. Most other system do one or the other: Spack allows
| you to choose.
| JorgeGT wrote:
| How does it compares to other HPC software managers such as
| easybuild?
| throw0101b wrote:
| From the 7th EasyBuild User Meeting (2022), 'A noob test: Spack
| "vs" EasyBuild' presentation is available on YouTube:
|
| * https://easybuild.io/eum22/#spack-vs-eb
|
| @tgamblin also presented 'The Spack 2022 Roadmap':
|
| * https://easybuild.io/eum22/#spack
|
| And will also present at 8th EUM (April):
|
| * https://easybuild.io/eum/#spack
| tgamblin wrote:
| If I have to pick one difference, the fundamental one is that
| Spack does dependency resolution with a solver, while EB does
| not.
|
| So, in Spack, you write a package.py file (like say the one for
| gromacs: https://github.com/spack/spack/blob/develop/var/spack/
| repos/...), and you can build that package with any of the
| versions/options/dependencies/etc. expressed in the package.
|
| With Easybuild, someone (maybe you?) has to write a specific
| configuration (easyconfig) for every build you want to do. Want
| to tweak a version? Write a new easyconfig. The dependencies
| point at specific versions, too, so now write configs for all
| the dependencies, and so on. There is a lot of copying/tweaking
| of file trees in the EB workflow.
|
| Aside from that: - Spack has a package database
| and allows you to query what is installed. - EB does
| not have "uninstall", just `rm -rf` - Spack builds from
| source and also handles binary packages (no binaries in EB)
| - Spack supports environments via `spack.yaml` / `spack.lock`;
| EB doesn't have that. - Spack doesn't require Lmod to
| work -- you can just `spack load` or `spack env activate` to
| use packages. - Spack builds with RPATH by default (much
| like Nix does) -- dependency libraries are found automatically
| even if you run an executable straight from its directory.
|
| There's more but Spack is a package manager, while EB is really
| set up to automate a certain type of installation common in
| HPC.
| stabbles wrote:
| Another point that I don't think gets emphasized a lot is that
| research software developers use spack as a dev tool on their
| laptop/cluster. Setting up easybuild locally is too much
| effort? If developers maintain spack recipes because they need
| them, it's much easier for sysadmins to deploy this software
| with spack too
| stonogo wrote:
| Spack recipes are more python-like, it is less tied to LMod,
| and its concretization algorithm has no real rival. Easybuild
| supports recursive modules and features to generalize
| boilerplate.
| [deleted]
| Moissanite wrote:
| Spack has significantly higher adoption than EasyBuild overall,
| though Spack usage has a US bias while EasyBuild is more
| popular with EU public sector HPC sites.
| amelius wrote:
| Does it have an "undo" option?
| stabbles wrote:
| It doesn't have it, but what sort of undo do you think of? Undo
| the latest installation on disk? Roll back to the previous
| environment?
| tgamblin wrote:
| I'd love to have both of these, to be honest.
| tgamblin wrote:
| Original author here -- since I know that people click the
| comments to decide whether to read further, here's a (biased?)
| summary:
|
| Spack is aimed at end users, developers, and admins. It's used
| primarily in HPC at the moment but it would be _great_ to see use
| _outside_ of the HPC community.
|
| Spack supports:
|
| 1. Basic installation (spack install foo, foo@3.1.2, foo@3.1.2
| +option, etc.)
|
| 2. Reproducible environments, via `spack.yaml` and `spack.lock`
| files that you can version in a repo. You can use this to build a
| custom software stack, build some dependencies for a project,
| etc.
|
| 3. Building _many_ versions of the same package, e.g. these are
| perfectly fine and can coexist: - spack install
| hdf5 - spack install hdf5 %clang - spack install
| hdf5 %oneapi@2023.2.0 - spack install hdf5@1.18.0
| cxxflags="-O3 -fast" target=cascadelake - spack install
| hdf5 +mpi ^mpich - spack install hdf5 +mpi ^openmpi
|
| 4. Both source builds and installation from relocatable binary
| caches
|
| 5. Lots of conditional features in packages that other systems do
| not offer, e.g.: - injecting compiler flags
| - building for specific uarch targets - optional
| dependencies - very fine-grained options (e.g. +/- cuda,
| set cuda_arch, etc.) - building the same package with
| different compilers - building the same package with
| different potentially ABI-incompatible dependencies like MPI or
| different boost versions.
|
| 5. Autogenerating things like container recipes, CI pipelines,
| Lmod/environment modules, etc.
|
| 6. Good support for building against external packages that may
| already be on your system.
|
| At a _very_ high level, Spack has:
|
| * Nix's installation model and configuration hashing
|
| * Homebrew-like packages, but in a more expressive Python DSL,
| and with more versions/options
|
| * A very powerful dependency resolver that doesn't just pick from
| a set of available configurations -- it configures your build
| according to _possible_ configurations.
|
| You could think of it like Nix with dependency resolution, but
| with a nice Python DSL. There is more on the "concretizer"
| (resolver) and how we've used ASP for it here:
|
| * "Using Answer Set Programming for HPC Dependency Solving",
| https://arxiv.org/abs/2210.08404
| toomuchtodo wrote:
| Really appreciate the effort you put into this. In a previous
| life I was an admin of a largeish cluster running Scientific
| Linux for the data side of an LHC detector, and was sad to hear
| FNAL discontinued it. HPC is always going to have a need for
| this sort of bespoke distro due to unique constraints, very
| cool to see this fill the HPC gap.
| nerdponx wrote:
| What do you think about Spack vs. Conda/Mamba? I've been a
| contented (maybe not "happy") Conda user for years. Is there
| any reason to switch? I'd be concerned about package
| availability.
| tgamblin wrote:
| We have a guide for this written by Adam Stewart, probably
| our most prolific (package) contributor:
|
| * https://spack.readthedocs.io/en/latest/replace_conda_homebr
| e...
|
| The thing you'll likely notice most about Spack vs.
| conda/mamba/rattler(?) is that it lets you pick your versions
| and options much more fluidly, and it'll build you a package
| from source if there's no binary for it. Spack is much more
| seamless for integrating binary installations with source
| builds. `conda-build` is a whole other tool outside the
| normal user workflow.
|
| Spack has over 7,000 packages at this point, so I don't think
| the lack of packages is going to hurt too much. We don't
| offer nearly as many public binaries yet, though, so the
| source builds may make the UX more painful, depending on what
| you're trying to do.
| throw0101b wrote:
| Spack has Anaconda as a package:
|
| * https://spack.readthedocs.io/en/latest/package_list.html#an
| a...
|
| * https://spack.readthedocs.io/en/latest/replace_conda_homebr
| e...
|
| So you can continue using it, but you also have a super-set
| of features for other things as well.
| yjftsjthsd-h wrote:
| Very neat:) Given the similarity in features, could you comment
| on how it compares to nix?
| 331c8c71 wrote:
| +100
|
| From what I saw the package definitions are in python. Given
| python is really an imperative language I don't see how spack
| could be comparably powerful for definitions and reuse.
| stabbles wrote:
| The package definitions are quite declarative even though
| the language is imperative, see an example here [1]. For
| hashes, Spack uses the normalized (comments, whitespace etc
| removed) abstract syntax tree.
|
| With Spack it's easier to contribute, you don't have to
| learn a new language as you need for Nix / Guix.
|
| [1] https://github.com/spack/spack/blob/develop/var/spack/r
| epos/...
| yjftsjthsd-h wrote:
| I could be persuaded to trade a certain amount of power for
| ease of use
| tgamblin wrote:
| The Spack DSL for defining versions, options, etc. is
| declarative. That part of a package exposes options to the
| solver and very much allows reuse, in the sense that the
| same package can be built _many_ different ways, and even
| with different dependencies. The whole system is
| parameterized in ways that Nix is not.
|
| The imperative part of a Spack package is the build recipe,
| which AFAICT is not so different from bundling a bash
| script in a Nix derivation. Just like Nix, it's included in
| our configuration hash, so if you change the recipe you get
| a different installation of the software.
| 331c8c71 wrote:
| Thanks for the answer.
|
| > That part of a package exposes options ... in the sense
| that the same package can be built many different ways,
| and even with different dependencies.
|
| It is quite a common pattern in nix to have package build
| flags and the dependencies as inputs in a derivation.
| This definitely makes it possible to build in different
| ways and with different dependencies.
| tgamblin wrote:
| Main differences with Nix:
|
| * Spack has a dependency solver (concretizer). nixpkgs is
| managed by humans who do the dependency solving for you over
| time. What this means practically is that you can install 5
| versions of some package with different dependencies and flag
| combinations with a few commands in Spack, while with Nix you
| would probably need to check out different commits of the
| nixpkgs repo and maybe do some hacking on nix derivations to
| get the same thing. Spack is fundamentally designed to help
| with combinatorics.
|
| * Nix builds all the way down to libc; Spack (currently)
| doesn't -- it's designed to live on an existing system.
|
| * Nix build environments are isolated (but require root to
| run); Spack's aren't as completely isolated and don't require
| root (so you can run Spack in your home directory.
|
| * Spack installation hashes are what Nix would call full
| configuration hashes -- they're configuration metadata
| hashes, not content hashes of the installation. So you could
| say we're not quite as committed to exact binary
| reproducibility, but you could also say that this allows us
| to support relocatable binaries (which Nix does not). Also,
| our metadata is pretty detailed.
|
| * Spack's DSL is Python; Nix is, well, Nix.
|
| Spack is very much inspired by Nix, and we talked about this
| a bit in the original paper here:
|
| * https://tgamblin.github.io/pubs/spack-sc15.pdf
| throw0101b wrote:
| > _6. Good support for building against external packages that
| may already be on your system._
|
| Able to use 'internal' packages (spack install openssl) or
| external packages (link against /usr/lib/libssl.so) on a per
| item basis: sometimes you want the newest code, but other times
| you want the OS package so that you can get security updates
| 'for free'.
|
| Most other system do one or the other: Spack allows you to
| choose.
| gdevenyi wrote:
| lmod integration?
| throw0101b wrote:
| Yes:
|
| * https://spack.readthedocs.io/en/latest/module_file_support.
| h...
|
| Both Lmod and (TCL) Modules: can generate either/both.
___________________________________________________________________
(page generated 2023-03-20 23:00 UTC)