Spack environment activation limits for in-place dependency upgrades

Supported limit for concurrent environments

Spack does not impose a numeric cap on the number of environments that share one installation root. The supported limit is behavioral: existing sessions keep working only while their installed prefixes are not overwritten, uninstalled, or garbage-collected. Activation is per shell and per process; it sets environment variables such as PATH, LD_LIBRARY_PATH, and Spack-specific variables, but it does not alter processes already launched from a previous environment.

For your upgrade, keep both the old and new environments available at the same time. New sessions activate the new environment; existing sessions continue using the old prefix until they exit. Do not run spack uninstall or garbage collection while old sessions may still reference those prefixes.

Compiler change and dependent rebuilds

A compiler change inside an environment is not a supported in-place mutation. Because the compiler is part of the spec hash, switching compilers normally causes the changed package and any dependents whose hashes change to be rebuilt under new prefixes. That is an affected sub-DAG, not automatically every package in the environment.

However, Spack does not perform ABI compatibility checks. If you pin dependents to old hashes, mark packages external, or otherwise bypass reconcretization, dependents linked against the changed dependency can fail at runtime. There is no documented pre-activation ABI oracle that guarantees safety before activation.

Detecting failures before activation

Detection is manual inspection plus smoke testing, not a built-in guarantee:

1. Run spack spec <application-root> in both environments and compare concretized hashes, compiler, and dependency list.
2. Run spack find -p to confirm old and new prefixes differ for the upgraded dependency.
3. Open a fresh shell, activate the new environment, and run the application smoke test while the old session remains active.
4. Switch users or sessions only after the smoke test passes.

Binary mirror guarantees

Matching architecture and OS does not guarantee a no-recompile upgrade. A buildcache entry is eligible only when the exact concretized spec hash—including compiler, version, variants, dependencies, and target—is present and trusted by the mirror. Otherwise Spack builds from source. Verify mirror trust and checksum policy before scripting an upgrade.

Verification commands

spack --version
spack env list
spack spec <application-root>
spack find -p <dependency>
spack buildcache list <exact-spec-hash>

Assumptions: you are using a recent Spack version where concretization includes compiler and dependency hashes in the spec hash. Exact flags and concretization reuse behavior vary by version, so check spack --version and the corresponding help before automating.

Missing diagnostic detail: confirm whether your application loads the dependency through rpath or through environment variables such as LD_LIBRARY_PATH. If it uses rpath, the old prefix must remain on disk until the session exits; if it uses environment variables, activation scope alone isolates sessions. This detail changes whether you need to preserve the old prefix beyond session exit.