Improve error message for requirements

[alalazo]

refers #33985

[alalazo]

@adamjstewart Not sure you consider this sufficient, but it's a low hanging fruit to improve the error message.

[adamjstewart]

Much better than it was before!

[alalazo]

@adamjstewart Then if you approve I'll merge it as soon as tests pass.

[haampie]

I don't like error messages created in the Spack core referring to spack commands, since spack commands are just one of the many ways this error can be triggered. This also causes weird error messages in buildcache commands for example, where some errors refer to spack buildcache args when using spack install or the other way around; they take different flags. So preferably this error message is created a few layers up. But at least something is better, so hitting approve.

[alalazo]

So preferably this error message is created a few layers up. But at least something is better, so hitting approve.

Hmm, I don't get your comment. This is a concretization error, that could happen only because of something in packages.yaml. The error message says how to use Spack to check your packages.yaml and doesn't refer to any other argument 🤔

[alalazo]

@spackbot run pipeline

[spackbot-app]

I've started that pipeline for you!

[haampie]

No, packages.yaml is a way to construct a ConfigScope, you can get those instances without packages.yaml files. I'm just saying the concretizer doesn't take a packages.yaml as input, that happens many layers up.

The point is that guessing the path that leads to an error where the error happens is always wrong, it should just bubble up as an exception until it reaches a layer where it's clear "you have this offending config file on the filesystem".

[adamjstewart]

@haampie I get where you're coming from. I just tried to install a package but had a typo in the name, and Spack told me I needed to run spack clean -m, which obviously isn't going to help. If we could make these more fine-grained that would be better.