Which Spack variants effectively minimize the build footprint for low-traffic workloads?

Answer

For low‑traffic workloads the most effective way to shrink a Spack concretization is to disable optional, heavyweight stacks that are not needed at runtime and to reuse system‑provided libraries whenever possible.

Confirmed facts

• Variants that toggle major dependencies (e.g., +cuda, +rocm, +mpi, +python, +docs, +examples, +tests) are declared in each package’s package.py and are resolved by the concretizer.
• Disabling these variants (~cuda, ~rocm, ~mpi, ~python, ~docs, ~examples, ~tests) and setting build_type=Release with ~debug typically removes the largest sub‑trees from the dependency DAG.
• Using system externals (via spack external find and packages: externals for libraries such as OpenSSL, zlib, readline) lets the concretizer reuse OS packages instead of building them from source, often yielding the single biggest footprint reduction.
• Enabling concretizer: unify: true in packages.yaml prevents duplicate builds of the same dependency across multiple specs in an environment.
• The impact of a variant can be measured before any build by comparing spack spec -I <pkg> +variant versus spack spec -I <pkg> ~variant; the difference in the -I list shows which packages would be newly installed.
• After a trial install, real size can be verified with du -sh $(spack location -i <pkg>) and the final dependency tree with spack find -d.

Recommended steps

1. Identify the target package (e.g., hdf5) and run spack info <pkg> to list all available variants and their defaults.
2. Create a baseline spec with the package’s default variants: spack spec -I <pkg>.
3. Iteratively disable variants that are known to be heavyweight and not required by the workload (start with ~cuda ~rocm ~mpi ~python ~docs ~examples ~tests). After each change, re‑run spack spec -I <pkg> and observe the delta in the to‑be‑installed list.
4. Set build_type=Release and ~debug for CMake‑based packages.
5. Add system externals for libraries you know are present on the host (e.g., packages: openssl: externals: - spec: openssl@1.1.1 prefix: /usr ) and rerun the spec to see if those dependencies disappear from the -I list.
6. Enable unification: add concretizer: unify: true to packages.yaml.
7. Perform a trial install: spack install <pkg>, then verify size with du -sh $(spack location -i <pkg>) and dependency count with spack find -d <pkg>.
8. If the workload runs successfully, consider the current variant set as the minimal viable footprint; otherwise re‑enable the variant that caused the failure and repeat.

Missing diagnostic detail

The exact package name is required to produce a concrete minimal‑variant list, because variant names and their dependency impact are package‑specific. Knowing which package (and, for libraries, what will link against it) determines which variants can be safely disabled.