Skip to content

Inconsistent handling of shortened versions #8957

@adamjstewart

Description

@adamjstewart

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('[email protected]') means the python version is in the closed-open range [2.7, 2.8).

When used in a depends_on statement, if I say:

depends_on('[email protected]')

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('[email protected]: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('[email protected]: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 %[email protected] ^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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions