Error when an anonymous spec is required for a virtual package#49385
Error when an anonymous spec is required for a virtual package#49385haampie merged 4 commits intospack:developfrom
Conversation
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]>
|
The error message seems a little opaque for interpretation from a casual user IMO. Is using 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. |
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 |
Signed-off-by: Massimiliano Culpo <[email protected]>
|
The error message has been improved with a hint, in case it's a single dependency. |
Signed-off-by: Massimiliano Culpo <[email protected]>
Signed-off-by: Massimiliano Culpo <[email protected]>
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:is absolutely equivalent to the more correct form:
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:users will now see this message:
Removing the
^in the requirement fixes concretization.