[Bug Fix (and docs too)] : Do not select @develop version by default#1933
[Bug Fix (and docs too)] : Do not select @develop version by default#1933tgamblin merged 4 commits intospack:developfrom
Conversation
algorithm, the intent was that the @develop version, although "greater" than numberic versions, is never preferred BY DEFAULT over numeric versions. To test this... suppose you have a package with no `preferred=True` in it, and nothing in `packages.yaml`, but with a `develop` version. For the sake of this example, I've hacked my `python/package.py` to work this way. Without bugfix (WRONG: user should never get develop by default): ``` python@develop%[email protected]~tk~ucs4 arch=darwin-elcapitan-x86_64 ... ``` With bugfix (RIGHT: largest numeric version selected): ``` [email protected]%[email protected]~tk~ucs4 arch=darwin-elcapitan-x86_64 ... ```
davydden
left a comment
There was a problem hiding this comment.
looks good to me, a few minor typos.
lib/spack/spack/concretize.py
Outdated
| if any(v.satisfies(sv) for sv in spec.versions)] | ||
|
|
||
| # The keys below show the order of precedence of factors used | ||
| # to select a version when concretizing. The the item with |
lib/spack/spack/concretize.py
Outdated
| # Numeric versions more preferred than non-numeric | ||
| v.isnumeric(), | ||
|
|
||
| # ---------- Regular case: use lateston-develop version by default. |
There was a problem hiding this comment.
lateston-develop -> latest non-develop?
|
@citibeth: do you mind adding a regression test for this in one of the spec tests? Could be a separate PR. |
|
I think it needs to be added, but I have no idea how. If someone wants to On Thu, Oct 6, 2016 at 10:40 AM, Todd Gamblin [email protected]
|
|
Look at the spec_semantics and concretize_preferences tests. They use mock packages in |
|
And how do I run the test while I'm developing it? On Thu, Oct 6, 2016 at 11:08 AM, Todd Gamblin [email protected]
|
|
@citibeth You can run the test by running |
|
Thanks for the info on unit/regression tests. I will not have time to write the tests today, but I believe this PR should be merged ASAP. See #1940. |
@tgamblin @davydden
This PR fixes a bug in #1561. #1561 was supposed to fix bugs, not change behavior in any significant way.
Before #1561, the
@developversion would not be selected in concretization, see comment from old code:After #1561, the
@developversion would be selected by default if it was available, breaking the pre-#1561 behavior. This could result in naive users (i.e. anyone not familiar with a particular package) "accidentally" obtaining the@developversion of a package without specifically requesting it.This PR fixes that bug introduced by #1561, with two changes:
v.isdevelop()tonot v.isdevelop(), ensuring that the@developversion will have lower default priority compared to numeric versionsv.isnumeric()from the key. This is already tested when comparing version numbers (the last part of the key), and could possibly mess things up if done separately.This PR also comes with related documentation improvements: