Spack seems to be inconsistently handling shorted versions.
depends_on
✔️ Edited by @haampie 2021-09-22: the issue here is no longer relevant, because depends_on('python@2.7') means the python version is in the closed-open range [2.7, 2.8).
When used in a depends_on statement, if I say:
Spack will install exactly Python 2.7, which will crash because 2.7 doesn't exist. I would instead expect it to install the latest 2.7.X. This is a long-standing bug documented in #921 and #1035.
As of now, the workaround has been to explicitly turn this into a version range:
depends_on('python@2.7.0:2.7.999')This works, but is unnecessarily wordy.
when=
✔️ Edited by @haampie 2021-09-22: This issue is fixed, since we can write when='@0.2:0.2.0', and the meaning is consistent with depends_on.
When used in a when= argument, if I say:
depends_on('r@3.4.0:3.4.9', when='@0.2')this will apply to both versions 0.2 and 0.2.2, as documented in #8950. Similarly, if I say:
patch('foo.patch', when='@3.2')this patch will be applied to both versions 3.2 and 3.2.1, as documented in #8320 and #8432.
As of now, there is no workaround for this problem. This may be fixed by #8320.
Compiler versions
This one is the worst of all. Let's say I have a GCC 7.2.0 compiler in my compilers.yaml. There are many other GCC compilers, but this is the only GCC 7 compiler I have. If I say:
$ spack install zlib %gcc@7
Spack will correctly deduce that I want it to use my GCC 7.2.0 compiler, but it will resolve the compiler as %gcc@7 in my spec, and install to the darwin-highsierra-x86_64/gcc-7 directory. The installation succeeds, but if I rerun:
$ spack install foo %gcc@7.2.0 ^zlib
Spack needs to reinstall zlib with the new GCC 7.2.0 compiler. I believe this bug is undocumented. In fact, I think it used to work properly. I used it all the time when I had multiple GCC compilers installed and I wanted to specify one.
The workaround is to use a version range, like %gcc@7:.
Proposal
All of these situations should be handled identically. Otherwise, it's confusing what behavior to expect. I propose the following behavior.
If a package.py/compilers.yaml contains both 3.2 and 3.2.1, 3.2 should refer to exactly 3.2 only.
If a package.py/compilers.yaml only contains 3.2.1, 3.2 should refer to any 3.2.X version.
@tgamblin @baberlevi @PDoakORNL @cyrush @davydden @goxberry @eschnett
Spack seems to be inconsistently handling shorted versions.
depends_on✔️ Edited by @haampie 2021-09-22: the issue here is no longer relevant, because
depends_on('python@2.7')means the python version is in the closed-open range [2.7, 2.8).When used in a
depends_onstatement, if I say:Spack will install exactly Python 2.7, which will crash because 2.7 doesn't exist. I would instead expect it to install the latest 2.7.X. This is a long-standing bug documented in #921 and #1035.
As of now, the workaround has been to explicitly turn this into a version range:
This works, but is unnecessarily wordy.
when=✔️ Edited by @haampie 2021-09-22: This issue is fixed, since we can write
when='@0.2:0.2.0', and the meaning is consistent withdepends_on.When used in a
when=argument, if I say:this will apply to both versions 0.2 and 0.2.2, as documented in #8950. Similarly, if I say:
this patch will be applied to both versions 3.2 and 3.2.1, as documented in #8320 and #8432.
As of now, there is no workaround for this problem. This may be fixed by #8320.
Compiler versions
This one is the worst of all. Let's say I have a GCC 7.2.0 compiler in my
compilers.yaml. There are many other GCC compilers, but this is the only GCC 7 compiler I have. If I say:$ spack install zlib %gcc@7Spack will correctly deduce that I want it to use my GCC 7.2.0 compiler, but it will resolve the compiler as
%gcc@7in my spec, and install to thedarwin-highsierra-x86_64/gcc-7directory. The installation succeeds, but if I rerun:$ spack install foo %gcc@7.2.0 ^zlibSpack needs to reinstall
zlibwith the new GCC 7.2.0 compiler. I believe this bug is undocumented. In fact, I think it used to work properly. I used it all the time when I had multiple GCC compilers installed and I wanted to specify one.The workaround is to use a version range, like
%gcc@7:.Proposal
All of these situations should be handled identically. Otherwise, it's confusing what behavior to expect. I propose the following behavior.
If a
package.py/compilers.yamlcontains both 3.2 and 3.2.1, 3.2 should refer to exactly 3.2 only.If a
package.py/compilers.yamlonly contains 3.2.1, 3.2 should refer to any 3.2.X version.@tgamblin @baberlevi @PDoakORNL @cyrush @davydden @goxberry @eschnett