Question
Which variant resolution strategy does Spack apply when cached binaries and explicit +flag specifications coexist?
Zo Nea
0 reputation · 13 Aug 2022, 15:20 UTC
115.8K views
Loading…
0 reputation · 13 Aug 2022, 15:20 UTC
Spack must resolve variant conflicts across a dependency graph when user-specified +flag directives interact with cached build artifacts. The concretization step selects concrete package versions, but the interaction between explicit flags and cached binaries introduces ambiguity in variant priority.
Cache staleness may mask source-level variant changes, and forcing +flag specifications can conflict with compiler compatibility on certain architectures. Additionally, the algorithm's priority resolution between user-defined flags and default variant selections remains unspecified for multi-package environments where downstream dependencies amplify the effect.
34775 reputation · 13 Aug 2022, 21:43 UTC
Spack treats the complete spec—including name, version, dependencies, and every variant flag—as the lookup key for its binary cache. When a user supplies explicit +flag specifications, those flags become part of the spec. If a cached binary exists whose variant set matches the spec exactly, Spack reuses it and skips a source build. Any difference in variant flags (even a single flag) causes Spack to discard the cached entry and rebuild the package from source to enforce the requested variant configuration.
spack+flag values propagate upward during concretization unless overridden by another explicit specification.spack install +debug to populate the cache.spack install +optimize and observe the install log for a message like “Building from source due to variant mismatch”.spack find --cached to list cached entries and compare their variant sets.If you do not see the variant‑mismatch message, please share the exact output of spack spec -l +debug +optimize so we can confirm whether the spec keys differ.
Use comments to ask for clarification. Post a solution as an answer.
5,560 reputation · 13 Aug 2022, 16:26 UTC
One point worth adding to the cache-key explanation: the +debug/+optimize case usually never reaches the cache stage at all. If a package declares those variants as conflicting in its package.py (via conflicts() or a single-valued variant), Spack's clingo-based concretizer fails with an unsatisfiable-spec error before any binary lookup happens. So the "priority rule" there isn't cache-vs-flag — it's that the spec is rejected outright and you must pick one value.
On precedence more generally: command-line variant flags outrank packages.yaml preferences, which in turn outrank package defaults. Since the full variant set feeds the spec hash, a cached binary built with different defaults simply has a different hash and is treated as incompatible — Spack doesn't "override" it, it just never matches it.
Caveat: this describes the clingo concretizer (roughly Spack 0.18+); older versions behaved differently. Worth verifying with spack spec -l yourspec and comparing hashes against spack find --format='{name} {hash} {variants}' on your actual version.