# Spack: A Package Manager That Keeps Every Build of the Same Library

> Spack builds and installs many versions and configurations of the same software side by side, which is why HPC sites reach for it instead of a system package manager. Here is how its spec syntax and concretizer work, how to get started, and where it stops being the right tool.

**spack/spack** — A flexible package manager that supports multiple versions, configurations, platforms, and compilers.

- Repository: https://github.com/spack/spack
- Website: https://spack.io
- Stars: 5,132 · Forks: 2,468
- Language: Python
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/spack-spack

## The problem Spack solves: many builds of the same package at once

A system package manager assumes one version of a library per machine. Spack assumes the opposite. Its README states that installing a new version of a package does not break existing installations, so many configurations of the same package can coexist. That property is what makes the project useful in scientific computing, where an application may need one specific BLAS, one specific MPI and one specific compiler, while a neighbouring application needs different ones.

The intended audience is not a laptop user installing a text editor. The README lists Linux, macOS, Windows and many supercomputers as supported platforms, and the topics attached to the repository include hpc and scientific-computing. Multi-user site deployments are explicitly discussed in the releases section, which recommends stable releases for cases that need very stable software installations. A single developer can use Spack, but the design pressure comes from shared clusters.

## Specs, pure-Python package files and the concretizer

The core mechanism is the spec. The README describes a simple spec syntax that lets users specify versions and configuration options, and says package files are written in pure Python so a package author can write a single script covering many different builds of the same package.

A spec is a request, not a command. It names a package and constrains it, and Spack has to turn that request into a concrete graph of dependencies with a compiler, an MPI provider and version numbers chosen. That resolution step is the concretizer. The repository's pyproject.toml lists clingo as a runtime dependency of the spack project, and the README's getting-started path installs a package directly, which means the concretizer runs on the user's machine rather than on a remote build service. This is the main architectural difference from binary-first package managers: the dependency graph is computed locally, and the resulting build is performed locally unless you configure otherwise.

Because package recipes live in a separate repository, spack-packages, the core repository is the engine and the recipes are a data set that moves independently. That split is visible in the README, which sends most contributors to spack-packages and reserves pull requests against the spack repository for changes to Spack itself. In practice it means the answer to "does Spack have package X" is a question about spack-packages, not about this repository.

## Installing Spack and running a first install

The README gives a three-step path. First, make sure Python and Git are present, then clone the repository shallowly:

```bash
git clone --depth=2 https://github.com/spack/spack.git
```

The depth of two keeps the clone small; it is enough to run Spack, but it is not a full history, so do not use this clone if you intend to develop against the repository.

Next, load the shell support script. The README gives one line per shell family:

```bash
# For bash/zsh/sh
. spack/share/spack/setup-env.sh

# For tcsh/csh
source spack/share/spack/setup-env.csh

# For fish
. spack/share/spack/setup-env.fish
```

After that, the README's example install is:

```bash
spack install zlib-ng
```

You should see Spack resolve the spec, fetch the sources and build the package. The first invocation may also bootstrap parts of Spack's own toolchain, which is why the README links a separate bootstrapping CI workflow; expect the first run to take noticeably longer than later ones. For syntax help rather than a full manual, the README points at `spack help --spec`, and `spack help --all` lists the full command set.

## Where Spack gets expensive: source builds and package churn

Spack's flexibility is paid for in build time. The README never promises binaries; the getting-started flow clones a repository and installs a package, and the package files are Python recipes describing how to build from source. On a cluster this is usually acceptable, because builds are queued and cached. On a laptop it is the part people underestimate.

The second cost is churn on the development branch. The releases section says that release branches receive backported bug fixes but do not advance package versions or make other changes that would change how Spack concretizes dependencies within a release branch. The implication is stated plainly enough: `develop` does get that churn. A site that tracks `develop` and expects reproducible concretization across months is working against the branch's purpose. The README's own recommendation for multi-user deployments is to base a deployment on a release branch and `git pull` for fixes, with `releases/latest` as the tag for the newest release.

A third limitation is environmental. Spack builds software, so it needs compilers, headers and, for many packages, MPI. It is not a substitute for a working toolchain, and it does not make an unsupported platform supported just because the Python code runs there.

## Spack compared with Conda and Nix

Conda and Nix are the two comparisons users ask about most, and the difference is not speed. Conda is built around distributing prebuilt binaries into isolated environments, with a solver that picks among published artifacts. Spack is built around building from source with a spec that can pin compilers and MPI providers, and its non-destructive install model keeps many configurations of the same package present simultaneously. If your problem is Python libraries, Conda's model fits better. If your problem is "this application needs GCC 11 with OpenMPI 4 and that one needs GCC 13 with MPICH", Conda's artifact model has no natural answer and Spack's spec does.

Nix shares the non-destructive, many-versions property and also builds from source recipes. The difference is in the recipe language and the target audience. Nix expressions are a functional language; Spack package files are pure Python, which the README presents as a deliberate choice so that one script can cover many builds. That matters for HPC, where the people writing recipes are often the application's own developers rather than distribution maintainers. Nix is also a general-purpose system manager; Spack's topics and documentation are aimed at HPC software stacks. Neither is a drop-in for the other, and the choice usually follows which language your team will actually maintain.

## Maintenance, releases and the two licences

The repository is not archived, and the last push was on 2026-09-22. Releases are frequent: v1.2.0 on 2026-06-21, v1.2.1 on 2026-07-06 and v1.2.2 on 2026-07-20. The default branch is `develop`, and the README is explicit that contributions should target it and must be PEP 8 compliant, pass unit, documentation and package build tests, and be signed off with `git commit --signoff` under the Developer Certificate of Origin. Signoff is required; cryptographic commit signing is not.

Licensing is unusual and worth reading before you redistribute. The repository carries both LICENSE-APACHE and LICENSE-MIT, and the GitHub metadata reports Apache-2.0. The NOTICE file and COPYRIGHT file are at the top level, and both licence files are included in the wheel build target in pyproject.toml. If you vendor Spack into a product, read both files and the NOTICE rather than assuming a single licence applies. That is a description of what the repository contains, not legal advice.

Upgrade cost splits by branch. On a release branch, the README's promise is bug fixes without changes to how dependencies concretize. On `develop`, package versions move, so a spec that resolved one way in June may resolve differently later; that is the trade you accept for newer recipes.

## Conclusion

Spack fits teams that need several compilers, MPI implementations or library versions installed at once on shared Linux, macOS or Windows machines, and sites that want to pin a deployment to a release branch. It is the wrong tool if you only need one Python environment, or if you want a package manager that never compiles anything. Before adopting it, verify that the packages you depend on exist in the spack-packages repository and that your concretizer, clingo, resolves the specs you care about.

## FAQ

### What is the Spack package manager?

Spack is a multi-platform package manager that builds and installs multiple versions and configurations of software, and it works on Linux, macOS, Windows and many supercomputers. Its distinguishing property is that installing a new version of a package does not break existing installations, so many configurations can coexist.

### How does Spack work?

You describe what you want with a spec, which can pin versions and configuration options, and Spack resolves that into a concrete dependency graph before building. Package files are written in pure Python, so one recipe can cover many different builds of the same package.

### How do I install Spack?

Make sure Python and Git are available, then run git clone --depth=2 https://github.com/spack/spack.git and source the setup script for your shell from spack/share/spack/. After that, spack install zlib-ng is the README's first example.

### Is Spack better than Conda?

They solve different problems. Conda distributes prebuilt binaries into environments, while Spack builds from source with specs that can pin compilers and MPI providers and keeps many configurations installed at once. For Python library environments Conda fits better; for varied compiler and MPI combinations on HPC systems Spack does.

### What is the difference between Spack and Nix?

Both allow many versions of the same package to coexist and both build from recipes. Spack's recipes are pure Python and its documentation targets HPC software stacks, while Nix uses a functional expression language and is a general-purpose system manager.

### How do I use Spack?

Load the shell setup script, then express what you want as a spec and pass it to spack install. The README points to spack help --spec for a syntax cheat sheet and to the hands-on tutorial for basic through advanced usage, including packaging and large HPC deployments.

## Sources

- [License: Apache-2.0](https://github.com/spack/spack/blob/develop/LICENSE)
- [Project website](https://spack.io)
- [README](https://github.com/spack/spack/blob/develop/README.md)
- [Releases](https://github.com/spack/spack/releases)
- [spack/spack on GitHub](https://github.com/spack/spack)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/spack-spack