Depending on the same package conditionally and unconditionally may cause concretization failures #1781
Description
I was trying to rewrite a long combinatorial chain of depends_on(boost) (+mpi is on by default)
depends_on("[email protected]:+thread+system+serialization+iostreams",
when='@:8.4.2~mpi')
depends_on("[email protected]:+thread+system+serialization+iostreams+mpi",
when='@:8.4.2+mpi')
depends_on("[email protected]:+thread+system+serialization+iostreams",
when='@8.5.0:~mpi~python')
depends_on("[email protected]:+thread+system+serialization+iostreams+mpi",
when='@8.5.0:+mpi~python')
depends_on("[email protected]:+thread+system+serialization+iostreams+python",
when='@8.5.0:~mpi+python')
depends_on(
"[email protected]:+thread+system+serialization+iostreams+mpi+python",
when='@8.5.0:+mpi+python')
in a much more concise and readable way
depends_on("[email protected]:+thread+system+serialization+iostreams")
depends_on("boost+mpi", when='+mpi')
depends_on("boost+python", when='@8.5.0:+python')
but i got an error Package boost requires variant +mpi, but spec asked for ~mpi
==> Error: Invalid spec: '[email protected]%[email protected]+atomic+chrono+date_time~debug+filesystem~graph~icu_support+iostreams+locale+log+math~mpi+multithreaded+program_options~python+random+regex+serialization+shared+signals+singlethreaded+system+test+thread+timer+wave arch=darwin-elcapitan-x86_64'. Package boost requires variant +mpi, but spec asked for ~mpi
It looks like once the normalized spec settles on
^[email protected]:+iostreams+serialization+system+thread
i.e. without ~mpi, Spack can not add to this from other conditional dependencies even within a single package.py.
It would be good to fix this (with unit tests) and also document in Developers Guide how Spack treats such cases. From other PRs i had an impression that Spack can make a union of dependencies, but it does not seem to be the case here. It could be that it worked by chance for other packages, that already rely on this functionality.