The concretizer should look into all the repositories for spec matches #15800
Description
This issue is following #15420 (comment) in particular:
Each use case regarded as work for the concretizer should be recorded as such: many of these things we'd like to solve could possibly be solved, but if we don't account for it in the design, then most likely it will be difficult to support
Rationale
The use-case exposed here is that of a Spack instance with:
- At least 2 repositories
- One package that has different recipes in both repositories
The two recipes may differ in variants, versions, dependencies etc. but need of course to refer to the same package (meaning the name of the spec must be the same). To create a similar situation one could for example:
$ spack repo create <mydir> test
$ spack repo add <mydir>and then copy and modify a package, say zlib, into the new repository with namespace test. Let's assume we delete the optimize variant and leave just a single 1.0 version in the test.zlib recipe.
In a similar situation the current behavior of Spack is to prefer the first repository in the list regardless of the abstract spec that is provided by the user. See for instance the third and fourth commands below:
Console output
$ spack --version
0.14.1-451-49aa28790
$ spack spec zlib
Input spec
--------------------------------
zlib
Concretized
--------------------------------
[email protected]%[email protected]+pic+shared arch=linux-ubuntu18.04-broadwell
$ spack spec builtin.zlib
Input spec
--------------------------------
zlib
Concretized
--------------------------------
[email protected]%[email protected]+optimize+pic+shared arch=linux-ubuntu18.04-broadwell
$ spack spec zlib+optimize
Input spec
--------------------------------
zlib+optimize
Concretized
--------------------------------
==> Error: trying to set variant "optimize" in package "zlib", but the package has no such variant [happened during concretization of zlib+optimize]
$ spack spec [email protected]
Input spec
--------------------------------
[email protected]
Concretized
--------------------------------
[email protected]%[email protected]+pic+shared arch=linux-ubuntu18.04-broadwellDescription
What a user might expect instead is that the concretizer can consider various aspects of the spec before selecting its namespace and thus that the output above is instead the following for the third and fourth commands:
$ # Even though the test repository has precedence +optimize can be
$ # satisfied only by the builtin repository, so choose that
$ spack spec zlib+optimize
Input spec
--------------------------------
zlib+optimize
Concretized
--------------------------------
[email protected]%[email protected]+optimize+pic+shared arch=linux-ubuntu18.04-broadwell
$ # Even though the test repository has precedence @1.2.11 can be
$ # satisfied only by the builtin repository, so choose that
$ spack spec [email protected]
Input spec
--------------------------------
[email protected]
Concretized
--------------------------------
[email protected]%[email protected]+optimize+pic+shared arch=linux-ubuntu18.04-broadwellAdditional information
The issue was raised in a PR proposing to add a second package repository in Spack, that will thus expose more frequently the behaviors above.
General information
- I have run
spack --versionand reported the version of Spack - I have searched the issues of this repo and believe this is not a duplicate