To run all tests manually, simply run:

spack test

To run a specific test only, run:

spack test versions

'dev' > '1.0' currently fails even thought examples in OP work. I don't see __gt__ defined, so i assumed it is not __lt__. Any ideas?

Look at the total_ordering decorator. It's a back port in external

I like it, and it seems logically consistent. The only problem I see is that having dev greater than all the other versions will make it always the default when present per-spec rules (and we will be forced to move preferred=True around). What about being always the lowest value ?

The only problem I see is that having dev greater than all the other versions will make it always the default when present per-spec rules (and we will be forced to move preferred=True around).

can one add somewhere a special treatment to ignore dev and take the highest version?

What about being always the lowest value ?

what do you mean? dev should be > than any version.

can one add somewhere a special treatment to ignore dev and take the highest version?

That would work also I guess.

what do you mean? dev should be > than any version.

The opposite : dev < any . It's less appealing logically (dev should be the bleeding edge), but will ensure that dev will never be the default if any other version is set.

The opposite : dev < any . It's less appealing logically (dev should be the bleeding edge), but will ensure that dev will never be the default if any other version is set.

but this is exactly the opposite of what i try to achieve. Say in deal.II the dev version now supports [email protected]:, so that's why i want to simplify (and actually make it possible at all, see OP) writing depends_on() for cases with dev.

I agree that dev is technically the latest and greatest version and should be considered greater than any other version. But Spack definitely shouldn't default to dev for security reasons, as @citibeth has mentioned many times. I think we should give dev special treatment when it comes to deciding which version to install by default.

But Spack definitely shouldn't default to dev for security reasons

that I agree 100%. My main goal here is easy writing of depends_on.

@tgamblin thanks for the link. I found what was missing.

@alalazo

can one add somewhere a special treatment to ignore dev and take the highest version?

That would work also I guess.

any hints where should i look at to add this?

@davydden I think the relevant code is in spack/concretize.py

@davydden Second guess : spack/preferred_packages.py -> PreferredPackages.version_compare

I would vote to call this develop, not dev. It makes things more clear.

@alalazo thanks for the hints. I looked at it and must admit so far i have no clue what/where to hack to make it ignore dev/develop when choosing a version...

@citibeth i am fine with develop, i can rename if all agree.

@alalazo @adamjstewart @citibeth @tgamblin made it working to ignore develop when conretizing. If it is all good, I can squash or i can drop the last commit which changes dev to develop. Let me know.

Does spack spec <package> ^gsl@develop still work with your changes? We'll want to change other packages from dev to develop if everyone else agrees. I don't usually use develop anyway so I'm impartial.

I have packages with a develop version (that downloads from the develop
git branch). Again... whichever way we standardize, someone will need to
change something.

On Thu, Jul 7, 2016 at 5:22 PM, Adam J. Stewart [email protected]
wrote:

Does spack spec ^gsl@develop still work with your changes?
We'll want to change other packages from dev to develop if everyone else
agrees. I don't usually use develop anyway so I'm impartial.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1190 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AB1cd7bvEWk2vakWgmJZvi2TFSv2RhYxks5qTW4NgaJpZM4JHT8y
.

Does spack spec ^gsl@develop still work with your changes?

yes, if I temporary hack develop version to gsl the following conretize just fine:

$ spack spec dealii@develop+gsl ^gsl@develop

Let's go with develop then. @master corresponds to the master branch, @develop corresponds to the develop branch, etc.

ok. i squashed into a single commit. From my side -- ready to merge if there are no further comments.

Oh, just thought of a good corner case. What if there is only a single version and it is develop? You should change the if-statement to:

if ver(valid_versions[0]) == ver('develop') and len(valid_version) > 1:
    spec.versions = ver([valid_versions[1]])

This could also happen when only develop meets some other kind of restraint, not just when develop is the only version. And it will prevent unintuitive index-out-of-bounds errors.

@adamjstewart thanks, indeed. Fixed it.

@davydden Sorry, that actually generates an index-out-of-bounds message too. I updated my comment.

@adamjstewart np. Fixed.

Oh, just thought of a good corner case. What if there is only a single
version and it is develop? You should change the if-statement to:

Good catch! This will be the common case when you're developing a new
package and haven't yet released any versions (but you used Spack to build
it from the beginning). See here for an example:

https://github.com/citibeth/spack/blob/d42a2ec6ef4324069fa7b5532404262d5ef6780a/var/spack/repos/builtin/packages/ettest/package.py

@tgamblin this is ready for review.

@davydden: I like it. I do think this needs some docs though, and it should probably be included in the section on fetching from VCS, as a "recommended" way to install from a branch like master. Can you add docs?

I'm not completely happy with the way that Spack handles provenance for VCS versions at the moment (though it's kind of my fault). The identifiers are made up by the packager, and they mean nothing once installed. I would like it a lot better if installing foo@develop queried the revision and possibly version tags for the foo repo and concretized to a more meaningful version like 1.1-124abce41f-develop, where 1.1 or v1.1 is the most "recent" tag and 124abce41f is a commit. You could do something similar for svn and hg. Obviously that's not in there yet but it's a direction this could evolve if people like the idea.

Can you add docs?

@tgamblin i added the docs. Let me know if you would like something changed.