Skip to content

Error when an anonymous spec is required for a virtual package#49385

Merged
haampie merged 4 commits intospack:developfrom
alalazo:solver/raise-if-anonymous-virtual-req
Mar 12, 2025
Merged

Error when an anonymous spec is required for a virtual package#49385
haampie merged 4 commits intospack:developfrom
alalazo:solver/raise-if-anonymous-virtual-req

Conversation

@alalazo
Copy link
Copy Markdown
Member

@alalazo alalazo commented Mar 9, 2025

When requiring a constraint on a virtual package, it makes little sense to use anonymous specs, and our documentation shows no example of requirements on virtual packages starting with ^.

Right now, due to how ^ is implemented in the solver, writing:

mpi:
  require: "^openmpi"

is absolutely equivalent to the more correct form:

mpi:
  require: "openmpi"

but the situation will change when % will shift its meaning to be a direct dependency.

To avoid, later, errors that are both unclear, and quite slow to get to the user, this commit makes anonymous specs under virtual requirements an error, and shows a clear error message pointing to the file and line where the spec needs to be changed.

Example

Using this spack.yaml:

# This is a Spack Environment file.
#
# It describes a set of packages to be installed, along with
# configuration settings.
spack:
  # add package specs to the `specs` list
  specs:
  - hdf5+mpi
  packages:
    mpi:
      require: "^openmpi"
  view: true
  concretizer:
    unify: true

users will now see this message:

$ spack concretize
==> Error: /tmp/spack-mje23iey/spack.yaml:11: expected a named spec, but got '^openmpi' instead. Maybe you meant 'openmpi'?

Removing the ^ in the requirement fixes concretization.

When requiring a constraint on a virtual package, it makes little
sense to use anonymous specs, and our documentation shows no example
of requirements on virtual packages starting with `^`.

Right now, due to how `^` is implemented in the solver, writing:
```yaml
mpi:
  require: "^openmpi"
```
is absolutely equivalent to the more correct form:
```yaml
mpi:
  require: "openmpi"
```
but the situation will change when `%` will shift its meaning to be a
direct dependency.

To avoid later errors that are both unclear, and quite slow to get to the user,
this commit makes anonymous specs under virtual requirements an error,
and shows a clear error message pointing to the file and line where the
spec needs to be changed.

Signed-off-by: Massimiliano Culpo <[email protected]>
@spackbot-app spackbot-app bot added core PR affects Spack core functionality tests General test capability(ies) labels Mar 9, 2025
@psakievich
Copy link
Copy Markdown
Contributor

The error message seems a little opaque for interpretation from a casual user IMO. Is using ^ or % the only thing that will currently trigger this? Could we add a hint on how to fix it as part of the message? Like "Try removin ^/% sigils from your spec" or "Spec delimiting sigils (^/%) are not allowed on virtual spec requirements."

If the error could be more broadly applied then that makes sense to keep it general. The use case here seems pretty targeted to me though.

@alalazo
Copy link
Copy Markdown
Member Author

alalazo commented Mar 9, 2025

Is using ^ or % the only thing that will currently trigger this?

No, any anonymous spec will. We can add a "maybe you meant xxx" in case we see dependencies, but other than that it's difficult to know what would be appropriate if the spec was +foo.

Signed-off-by: Massimiliano Culpo <[email protected]>
@alalazo
Copy link
Copy Markdown
Member Author

alalazo commented Mar 9, 2025

The error message has been improved with a hint, in case it's a single dependency.

Signed-off-by: Massimiliano Culpo <[email protected]>
@spackbot-app spackbot-app bot added the gitlab Issues related to gitlab integration label Mar 9, 2025
psakievich
psakievich previously approved these changes Mar 10, 2025
Copy link
Copy Markdown
Contributor

@psakievich psakievich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

haampie
haampie previously approved these changes Mar 11, 2025
Signed-off-by: Massimiliano Culpo <[email protected]>
@haampie haampie merged commit d352b71 into spack:develop Mar 12, 2025
37 checks passed
@alalazo alalazo deleted the solver/raise-if-anonymous-virtual-req branch March 12, 2025 07:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

core PR affects Spack core functionality gitlab Issues related to gitlab integration tests General test capability(ies)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants