solver: do a precheck for non-existing and deprecated versions by tgamblin · Pull Request #51555 · spack/spack

tgamblin · 2025-11-12T06:52:33Z

The solver can report errors for versions that do not exist, but it's easier and often faster to check for these beforehand. Also the solver doesn't know about deprecated versions, so we can generate a much clearer error message with a pre-pass.

Create a method, input_spec_version_check, that checks input specs for versions that we know statically to make the solve unsat.
Error if any version in an input spec is: 1. Unknown (not in any package definition and not possible via setup), or 2. Deprecated (i.e. it can only be satisfied by deprecated versions), and advise the user ot use --deprecated if so.
tests

tgamblin · 2025-11-12T06:55:49Z

I think this will be popular. Don't merge this before @alalazo or @becker33 have a chance to review -- I am not certain this i handling all ways a version can be possible/impossible. It can also probably be quicker (i.e. we could do some of these checks before setup) but I went for something simple and conservative for now, since setup determines all possible versions.

One thought: we used to allow people to spack install [email protected], where x.y.z was a version that was not explicitly in any package.py. Spack would just extrapolate the URL. I don't think we do that anymore and I cannot remember when we stopped supporting it. I think we should allow that, but maybe with an argument to install like --try or something so that by default we warn about unknown versions.

Thoughts?

becker33

Perfectly reasonable if it's not in scope for this PR but it would be great to do this for requirements as well.

lib/spack/spack/solver/asp.py

psakievich · 2025-11-12T18:05:52Z

Perfectly reasonable if it's not in scope for this PR but it would be great to do this for requirements as well.

Along this vein, perhaps we should extract this into two methods? input_spec_check which calls input_spec_check_versions? I like the idea of putting all our pre-solve validations into one parent method that loops over all the specs, and then the individual checks would be per spec.

I was just chatting with @vbrunini about doing the same thing for the intersection of externals and requirements due to added sensitivity of specifying externals post #51118. I'm not sure if that would be better to do presolve or via an error message in the solve ATM.

mwkrentel · 2025-11-13T07:36:09Z

I tried a few things here with various versions of cmake.

First, with a version that doesn't exist, the old message doesn't
identify the real problem.

$ spack spec cmake @3.31.5
==> Error: failed to concretize `[email protected]` for the following reasons:
     1. Cannot satisfy '[email protected]' 4(3.12.4)
        required because [email protected] requested explicitly 
     2. Cannot satisfy '[email protected]' 2(3.12.4)

I get the same error with cmake @3.31.8 which is deprecated.

With the patch, I get this which is more helpful.

$ spack spec [email protected]
==> Error: No version exists that satisfies these input specs:
    [email protected]

$ spack spec [email protected]
==> Error: The following input specs can only be satisfied by deprecated versions:
    [email protected]
Run with --deprecated to allow Spack to use these versions.

If I specify the version in packages.yaml either with version: [3.31.8]
(which is deprecated) or with require: "[email protected], or with another
package that has depends_on("[email protected]") I get:

$ spack  spec  cmake
==> Error: Version requirement 3.31.8 on cmake for cmake cannot match
  any known version from package.py or externals

This is the same error as with develop. I assume this occurs after
the sanity check and doesn't say "deprecated" because the concretizer
has thrown those away. Still, it's better than Cannot satisfy '[email protected]'

Btw, I understand why the concretizer throws away deprecated versions
(and thus they don't exist) and I agree that's a good idea for speed,
but then the error should say "this version doesn't exist OR is deprecated.

I was maybe a little disappointed with version: [3.31.8, 3.29.6]

$ spack spec cmake
==> Error: Preference for version 3.31.8 does not match any known version
  of cmake (in its package.py or any external)

Here, 3.31.8 is deprecated, so why stop there and error out when
there's another valid version in the list?

Anway, I think it's a fine sanity check that should catch a lot of common error cases.

Probably there will be opportunities for other sanity checks that are
simple and cover common mistakes, even if they don't detect everything.

The solver can report errors for versions that do not exist, but it's easier and often faster to check for these beforehand. Also the solver doesn't know about deprecated versions, so we can generate a much clearer error message with a pre-pass. - [x] Create a method, `input_spec_version_check`, that checks input specs for versions that we know statically to make the solve unsat. - [x] Error if any version in an input spec is: 1. Unknown (not in any package definition and not possible via setup), or 2. Deprecated (i.e. it can only be satisfied by deprecated versions), and advise the user ot use `--deprecated` if so. Signed-off-by: Todd Gamblin <[email protected]>

Signed-off-by: Gregory Becker <[email protected]>

due to zig error Signed-off-by: Gregory Becker <[email protected]>

Signed-off-by: Gregory Becker <[email protected]>

This reverts commit 690fd55. Signed-off-by: Gregory Becker <[email protected]>

Signed-off-by: Gregory Becker <[email protected]>

Signed-off-by: Greg Becker <[email protected]>

Signed-off-by: Todd Gamblin <[email protected]>

* solver: do a precheck for non-existing and deprecated versions The solver can report errors for versions that do not exist, but it's easier and often faster to check for these beforehand. Also the solver doesn't know about deprecated versions, so we can generate a much clearer error message with a pre-pass. - [x] Create a method `impossible_dependencies_check`, that checks input specs for non-conditional impossible dependencies - [x] Create a method, `input_spec_version_check`, that checks input specs for versions that we know statically to make the solve unsat. - [x] Error if any version in an input spec is: 1. Unknown (not in any package definition and not possible via setup), or 2. Deprecated (i.e. it can only be satisfied by deprecated versions), and advise the user ot use `--deprecated` if so. Signed-off-by: Todd Gamblin <[email protected]> Signed-off-by: Gregory Becker <[email protected]> Co-authored-by: Gregory Becker <[email protected]>

* solver: do a precheck for non-existing and deprecated versions The solver can report errors for versions that do not exist, but it's easier and often faster to check for these beforehand. Also the solver doesn't know about deprecated versions, so we can generate a much clearer error message with a pre-pass. - [x] Create a method `impossible_dependencies_check`, that checks input specs for non-conditional impossible dependencies - [x] Create a method, `input_spec_version_check`, that checks input specs for versions that we know statically to make the solve unsat. - [x] Error if any version in an input spec is: 1. Unknown (not in any package definition and not possible via setup), or 2. Deprecated (i.e. it can only be satisfied by deprecated versions), and advise the user ot use `--deprecated` if so. Signed-off-by: Todd Gamblin <[email protected]> Signed-off-by: Gregory Becker <[email protected]> Co-authored-by: Gregory Becker <[email protected]> Signed-off-by: Gregory Becker <[email protected]>

* solver: do a precheck for non-existing and deprecated versions The solver can report errors for versions that do not exist, but it's easier and often faster to check for these beforehand. Also the solver doesn't know about deprecated versions, so we can generate a much clearer error message with a pre-pass. - [x] Create a method `impossible_dependencies_check`, that checks input specs for non-conditional impossible dependencies - [x] Create a method, `input_spec_version_check`, that checks input specs for versions that we know statically to make the solve unsat. - [x] Error if any version in an input spec is: 1. Unknown (not in any package definition and not possible via setup), or 2. Deprecated (i.e. it can only be satisfied by deprecated versions), and advise the user ot use `--deprecated` if so. Signed-off-by: Todd Gamblin <[email protected]> Signed-off-by: Gregory Becker <[email protected]> Co-authored-by: Gregory Becker <[email protected]>

…#51555) * solver: do a precheck for non-existing and deprecated versions The solver can report errors for versions that do not exist, but it's easier and often faster to check for these beforehand. Also the solver doesn't know about deprecated versions, so we can generate a much clearer error message with a pre-pass. - [x] Create a method `impossible_dependencies_check`, that checks input specs for non-conditional impossible dependencies - [x] Create a method, `input_spec_version_check`, that checks input specs for versions that we know statically to make the solve unsat. - [x] Error if any version in an input spec is: 1. Unknown (not in any package definition and not possible via setup), or 2. Deprecated (i.e. it can only be satisfied by deprecated versions), and advise the user ot use `--deprecated` if so. Signed-off-by: Todd Gamblin <[email protected]> Signed-off-by: Gregory Becker <[email protected]> Co-authored-by: Gregory Becker <[email protected]>

* solver: do a precheck for non-existing and deprecated versions The solver can report errors for versions that do not exist, but it's easier and often faster to check for these beforehand. Also the solver doesn't know about deprecated versions, so we can generate a much clearer error message with a pre-pass. - [x] Create a method `impossible_dependencies_check`, that checks input specs for non-conditional impossible dependencies - [x] Create a method, `input_spec_version_check`, that checks input specs for versions that we know statically to make the solve unsat. - [x] Error if any version in an input spec is: 1. Unknown (not in any package definition and not possible via setup), or 2. Deprecated (i.e. it can only be satisfied by deprecated versions), and advise the user ot use `--deprecated` if so. Signed-off-by: Todd Gamblin <[email protected]> Signed-off-by: Gregory Becker <[email protected]> Co-authored-by: Gregory Becker <[email protected]> Signed-off-by: Gregory Becker <[email protected]>

becker33 · 2026-02-02T21:40:46Z

This PR does not apply cleanly to releases/v1.0 and will be dropped from v1.0.3

tgamblin requested a review from alalazo November 12, 2025 06:52

alalazo self-assigned this Nov 12, 2025

tgamblin requested a review from becker33 November 12, 2025 06:55

tgamblin force-pushed the detect-impossible-specs-early branch from 789af31 to af25514 Compare November 12, 2025 10:02

becker33 requested changes Nov 12, 2025

View reviewed changes

lib/spack/spack/solver/asp.py Outdated Show resolved Hide resolved

alalazo mentioned this pull request Nov 13, 2025

Backports: v1.1.0 #51533

Merged

17 tasks

becker33 added the v1.1.1 label Nov 13, 2025

becker33 added the v1.0.3 PRs to backport for v1.0.3 label Nov 24, 2025

harshula mentioned this pull request Dec 9, 2025

spack concretize hangs when installing cmake with a deprecated gcc #51279

Open

3 tasks

github-actions bot added unit-tests solver labels Dec 31, 2025

becker33 closed this Dec 31, 2025

becker33 reopened this Dec 31, 2025

tgamblin and others added 7 commits January 2, 2026 16:14

handle virtuals and versions on dependencies

3560721

Signed-off-by: Gregory Becker <[email protected]>

regression tests for new version errors

b78f0ed

Signed-off-by: Gregory Becker <[email protected]>

more type checks

f946185

Signed-off-by: Gregory Becker <[email protected]>

fixup

767202c

Signed-off-by: Gregory Becker <[email protected]>

flail around trying to make mypy happy

900605c

Signed-off-by: Gregory Becker <[email protected]>

satisfy the mypy monster

b4ae4f3

Signed-off-by: Gregory Becker <[email protected]>

becker33 force-pushed the detect-impossible-specs-early branch from a8cf386 to b4ae4f3 Compare January 3, 2026 00:24

github-actions bot added ci Issues related to Continuous Integration style labels Jan 3, 2026

revert ruamel version: 0.19.0 fails to install from pip

690fd55

due to zig error Signed-off-by: Gregory Becker <[email protected]>

becker33 force-pushed the detect-impossible-specs-early branch from 824e63b to 690fd55 Compare January 3, 2026 00:33

becker33 added 2 commits January 6, 2026 09:29

fix test for new error message

5974d6e

Signed-off-by: Gregory Becker <[email protected]>

make spec solver sanity checks account for virtuals and conditional deps

4bb0f37

Signed-off-by: Gregory Becker <[email protected]>

becker33 and others added 4 commits January 6, 2026 12:01

Revert "revert ruamel version: 0.19.0 fails to install from pip"

b475737

This reverts commit 690fd55. Signed-off-by: Gregory Becker <[email protected]>

missing import

34eb3b2

Signed-off-by: Gregory Becker <[email protected]>

Merge branch 'develop' into detect-impossible-specs-early

9a86154

Signed-off-by: Greg Becker <[email protected]>

minor cleanups

b25ccda

Signed-off-by: Todd Gamblin <[email protected]>

becker33 approved these changes Jan 7, 2026

View reviewed changes

becker33 merged commit 744e44a into develop Jan 7, 2026
34 checks passed

becker33 deleted the detect-impossible-specs-early branch January 7, 2026 18:06

becker33 mentioned this pull request Jan 10, 2026

Backports: v1.1.1 #51835

Merged

2 tasks

becker33 added this to the v1.2.0 Core Priorities milestone Jan 14, 2026

becker33 mentioned this pull request Jan 14, 2026

Concretizer errors: pre-solve check for impossible requirements #51843

Open

1 task

becker33 removed the v1.0.3 PRs to backport for v1.0.3 label Feb 2, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

solver: do a precheck for non-existing and deprecated versions#51555

solver: do a precheck for non-existing and deprecated versions#51555
becker33 merged 14 commits intodevelopfrom
detect-impossible-specs-early

tgamblin commented Nov 12, 2025 •

edited by becker33

Loading

Uh oh!

tgamblin commented Nov 12, 2025

Uh oh!

becker33 left a comment

Uh oh!

Uh oh!

psakievich commented Nov 12, 2025 •

edited

Loading

Uh oh!

mwkrentel commented Nov 13, 2025

Uh oh!

Uh oh!

becker33 commented Feb 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Conversation

tgamblin commented Nov 12, 2025 • edited by becker33 Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tgamblin commented Nov 12, 2025

Uh oh!

becker33 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

psakievich commented Nov 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mwkrentel commented Nov 13, 2025

Uh oh!

Uh oh!

becker33 commented Feb 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

tgamblin commented Nov 12, 2025 •

edited by becker33

Loading

psakievich commented Nov 12, 2025 •

edited

Loading