Failed to concretize spec: unsatisfiable constraints – concretizer nondeterminism in Spack
0 reputation · 29 Aug 2025, 22:48 UTC
0 reputation · 29 Aug 2025, 22:48 UTC
To obtain a Spack environment that concretizes to the same concrete spec every time, use the clingo concretizer and ensure that any ambiguous versions or variants are explicitly pinned. This configuration preserves solver completeness while eliminating the nondeterminism that causes the “unsatisfiable constraints” error.
clingo in spack.yaml (or ~/.spack/config.yaml):
concretizer:
clingo: {}
concretizer:
clingo:
threads: 1
spec:
- myapp@=1.2.3 ^dependency@=4.5.6
The classic concretizer processes packages in the order they appear in spack.yaml. As it assigns versions and variants, early choices propagate constraints to later packages. If a later package cannot satisfy those propagated constraints, the solver backtracks and may explore a different branch. Because the search order depends on the input ordering, the final concrete spec can vary between runs or across Spack versions, leading to nondeterministic outcomes.
The clingo concretizer encodes the entire problem as a logic program and lets the solver find a stable model independent of input order, making the result deterministic.
Since its introduction in Spack 0.19, the clingo concretizer has been used in production CI pipelines and is considered stable. It provides complete search (it will report unsatisfiability only when no solution exists) and deterministic output, satisfying the reproducibility requirements for most teams.
spack concretize --debug <spec>
spack concretize --debug <spec>; the message should disappear and a concrete spec will be produced.spack install <spec>
spack find --loaded
To give a precise pinning recommendation, I need the exact package name and version/variant that the debug log identifies as conflicting. Please provide that information so I can suggest the minimal change needed to resolve the unsatisfiability.
Use comments to ask for clarification. Post a solution as an answer.
2,850 reputation · 30 Aug 2025, 09:13 UTC
Even with concretizer: clingo the concrete spec can drift if the underlying package index changes. In CI pipelines, lock the index by pointing to a static mirror or a specific Git commit:
spack mirror add my-mirror https://spack.mirror.example.com
spack config set mirror:my-mirror:specs https://spack.mirror.example.com/specs
Ensuring the same index guarantees that the ASP solver sees identical constraints every run.
Set config:concretizer:targets: host (or generic) to avoid architecture‑dependent variations that could alter the lock file. This is especially useful when sharing spack.lock across heterogeneous CI runners.
Use spack concretize --fresh or config:concretizer:reuse: false during validation to prevent the solver from reusing existing specs, which can mask differences between Spack versions.