@tgamblin

Is this a change? Last I knew, 2.6:2.7 would give everything UP THROUGH
2.7 --- but not 2.7.1, 2.7.2, etc.

On Wed, Oct 5, 2016 at 5:44 PM, Adam J. Stewart [email protected]
wrote:

@adamjstewart commented on this pull request.

In var/spack/repos/builtin/packages/petsc/package.py:

@@ -71,7 +75,7 @@ class Petsc(Package):
depends_on('mpi', when='+mpi')

 # Build dependencies

• depends_on('python @2.6:2.7')
• depends_on('python @2.6:2.8', type='build')

The version range was correct. The range is inclusive, as in 2.6:2.7
means any version of 2.6.X or 2.7.X. You can confirm this by running spack
spec petsc. For me, it chooses [email protected].

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#1920 (review), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB1cdyEv50gUzLwOX8ltdcBUtI5BVuCbks5qxBo3gaJpZM4KPTPR
.

@citibeth: 2.7 has always been intended to include 2.7.1, 2.7.2, etc.

You might be thinking about how [email protected] only includes 2.7 and not 2.7.1, etc. And how [email protected]:2.7 does the same thing, making [email protected]:2.8 necessary. That's a bug, but doesn't affect this package.

Yes thanks, that was it.

On Wed, Oct 5, 2016 at 6:01 PM, Adam J. Stewart [email protected]
wrote:

You might be thinking about how [email protected] only includes 2.7 and not 2.7.1,
etc. And how [email protected]:2.7 does the same thing, making [email protected]:2.8
necessary. That's a bug, but doesn't affect this package.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#1920 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB1cd1E7PRJEV4WeM7NNGKJh1AqFF_Nnks5qxB4rgaJpZM4KPTPR
.

Yeah, sorry for that. That is a concretization issue. The concretizer thinks that if a package has a single version that is not a range or a list, that it's concrete, so if you say 2.7 on the command line it never gets matched against known versions. But 2.7, if compared to other versions, will be satisfied by 2.7.1, 2.7.8.1, etc.

Probably a version needs to know whether it is exact, so the concretizer doesn't have to use a kludgy test like it does. This would also be useful for users -- I have thought about allowing "exact" version literals like 2.7. (period at the end) to indicate the version is exactly v2.7 and shouldn't match anything else.