Stop Installing Packages One at a Time: Spack Environments as Your Source of Truth

If you manage scientific software on a cluster, you know the failure mode: someone runs spack install hdf5+mpi on Monday, someone else installs netcdf-c on Thursday, and three weeks later you discover the two pulls in different MPI builds and nothing links together. Each install was fine in isolation; the collection is a mess. Spack environments exist precisely to fix this, and they change the question from "what did I install?" to "what did I declare?"

The thesis is simple: treat your software stack as a declared, version-controlled artifact — a spack.yaml plus a spack.lock — rather than an accumulation of shell history. Concretization does the hard work; the lockfile makes it repeatable.

What an environment actually buys you

An environment is a directory containing a spack.yaml that lists abstract specs — your wishes, like hdf5+mpi %gcc. When you run spack concretize, Spack's solver resolves all of those wishes together into one consistent dependency graph: concrete versions, compilers, variants, and dependency versions that satisfy every constraint simultaneously. That joint resolution is the whole point. Installing packages ad hoc lets each install pick its own dependency versions; concretizing together forces one MPI, one compiler toolchain, one graph.

The result is recorded in spack.lock, which stores the fully concretized specs with hashes. Commit both files next to your application code, and a colleague (or future you) can run spack install from the lockfile and get the same directed acyclic graph (DAG) of packages.

A minimal worked example

Run these anywhere Spack is installed; no special permissions needed since everything lands in Spack's own install tree. This assumes a reasonably current Spack release — exact flags and defaults do shift between versions, so check spack --version and the docs for yours.

# Create and activate an environment
spack env create mystack
spack env activate mystack

# Declare what you want (abstract specs)
spack add hdf5+mpi %gcc
spack add netcdf-c

# Resolve the whole graph at once
spack concretize

# Build it (this can take a while for large stacks)
spack install

To verify the result, run spack find while the environment is active. You should see each spec with a concrete version, compiler, and a hash — not the abstract form you typed. If spack find still shows abstract specs, concretization didn't happen or you're not inside the environment.

The reproducibility check: copy spack.yaml and spack.lock to a clean machine or container with the same Spack version, activate the environment, and run spack install. Then compare spack find output — the hashes should match. If they don't, the usual suspects are a different Spack release (solver defaults evolve) or different external package configuration.

Views and modules: making the stack usable

A solved graph isn't yet something users can run. Two common bridges:

• Views. Enabling a view in spack.yaml creates a merged prefix — a single directory symlinking every installed package, like a traditional /usr/local. Users put one directory on PATH and LD_LIBRARY_PATH and they're done. No module system required.
• Modules. Spack can generate Tcl or Lmod modulefiles from the environment, so the environment doubles as the source of truth for what shows up in module avail on a cluster.

One gotcha with views: because everything is symlinked into one prefix, a view can mask missing RPATHs that would only surface when running from the original install prefixes. If a binary works from the view but fails when loaded via modules with a library-not-found error, that's the first place to look.

Externals: the portability trade-off

You'll typically mark system-provided software — MPI, CUDA, OS libraries — as external in packages.yaml so Spack uses the platform's builds instead of compiling its own. This keeps builds fast and ABI-compatible with the machine. The cost: those externals are the main source of non-portability between sites. Your lockfile guarantees the DAG, not bit-for-bit binaries. Compiler flags from externals, microarchitecture detection, and local config can all still change what gets built. Treat externals as site-specific configuration that travels separately from the lockfile.

Limitations worth planning around

• Concretization is version-sensitive. The same spack.yaml can resolve differently across Spack releases as the solver and package recipes evolve. Pin the Spack version alongside the lockfile.
• Source builds are slow. A full stack of compilers, MPI, and scientific libraries can take hours. Binary caches (buildcaches) make rebuilds practical; without one, "reproducible" can mean "reproducible by Friday."
• The lockfile is not a container image. It pins the graph, not the bits. For stronger guarantees, pair it with buildcaches or containers.

Where to start

Pick one workflow that's currently a pile of ad hoc installs, declare it as an environment, and commit the spack.yaml and spack.lock to the same repo as the code that depends on it. Then do the one exercise that builds real intuition: change a single constraint — say, bump an hdf5 version — re-run spack concretize, and watch how the solver re-resolves the graph and updates the lockfile. Once you've seen the solver do that bookkeeping for you, going back to one-off installs feels like editing a lockfile by hand.