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
--------------------------------
zlib@1.0%gcc@9.0.1+pic+shared arch=linux-ubuntu18.04-broadwell
$ spack spec builtin.zlib
Input spec
--------------------------------
zlib
Concretized
--------------------------------
zlib@1.2.11%gcc@9.0.1+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 zlib@1.2.11
Input spec
--------------------------------
zlib@1.2.11
Concretized
--------------------------------
zlib@1.2.11%gcc@9.0.1+pic+shared arch=linux-ubuntu18.04-broadwell
Description
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
--------------------------------
zlib@1.2.11%gcc@9.0.1+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 zlib@1.2.11
Input spec
--------------------------------
zlib@1.2.11
Concretized
--------------------------------
zlib@1.2.11%gcc@9.0.1+optimize+pic+shared arch=linux-ubuntu18.04-broadwell
Additional 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
This issue is following #15420 (comment) in particular:
Rationale
The use-case exposed here is that of a Spack instance with:
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:
and then copy and modify a package, say
zlib, into the new repository with namespacetest. Let's assume we delete theoptimizevariant and leave just a single1.0version in thetest.zlibrecipe.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
Description
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:
Additional 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
spack --versionand reported the version of Spack