crates.io: Dependency line given wrong if suffixes are used

[nwin]

https://crates.io/crates/image claims that image = "~0.2.0-alpha.1" should work. It doesn't.

The error message is:

The given version requirement is invalid.

image = "~0.2.0" on the other hand works.

[alexcrichton]

This looks like it's actually because rust-lang/semver doesn't parse this version requirement. It looks like it currently only has support for requirements with major/minor/patch numbers (no identifiers and such).

[nwin]

It actually re-implements the complete parsing. It there any specific reason why Predicate can't simply be defined as

struct Predicate {
    op: Op,
    version: Version

}

and re-use the most logic from Version?

edit: I accidentally tabbed out the box and submitted before finishing…
edit2: because of * of course, never mind…

[alexcrichton]

I believe the error messages here have improved some time since this was opened, and semver was also updated with support for more requirements, so I think this is fixed. I'm going to close this for now, but feel free to reopen if you see it again!

[nwin]

This is still not fixed.

Going back to an old version crates.io, now claims that image = "0.2.0-alpha.12" should be used. Inserting that into Cargo.toml results in the error message: failed to parse manifest at .../Cargo.toml

In fact the situation worsened because the error message is less helpful.

[alexcrichton]

Ah well, looks like there's still some work to do!

[ghost]

Comparing prerelease versions is fixed in dtolnay/semver#54 (not published to crates.io yet though)

[steveklabnik]

I can cut a release if this is needed more quickly, I was going to wait until all the new comparisons work. first

[ghost]

No urgency, just ran into this myself so I'm linking the relevant issues up.

I suppose linking to dtolnay/semver#58 is more useful in that case.

[alexcrichton]

Yeah I'm fine updating semver whenever it's ready, thanks for the update @eljay!

[steveklabnik]

As part of that, @alexcrichton , any chance you could find some time to file those issues about what oyu want to see for 1.0?

[carols10cents]

I believe this is a dupe of #2337 which was fixed by dtolnay/semver#74 and #2348, so I think this can be closed.

[alexcrichton]

Aha yes indeed, thanks @carols10cents!

[Byron]

I am still running into this, and believe this is easily reproduced by trying to run cargo build --verbose on a directory with this Cargo.toml file:

[package]
name = "version-issue"
version = "0.3.6+20141121"

[dependencies.google-tasks1]
version = "0.1.15+123"

Even though package.version parses fine, it does not in case of dependencies.google-tasks1.version.

The file will parse correctly if the +123 part is removed.

Meta

# same issue for both stable and nightly
$ cargo --version
cargo 0.12.0-nightly (6b98d1f 2016-07-04)
[...]
cargo 0.13.0-nightly (398de25 2016-09-09)

[carols10cents]

@Byron I did a little investigating, and I think you're seeing dtolnay/semver#88. I found that through #2939, which sounds like the same symptoms as you're reporting here. So it's a bug with the semver crate!

[Byron]

@carols10cents Thanks for figuring this out ! I just subscribed to the linked issue on the semver crate. Seems like an easy fix with possibly huge impact.

[Byron]

@carols10cents Apparently the comment to you convinced me to make this PR, which should fix this issue once it bubbled up to cargo.

[carols10cents]

@Byron awesome!!!

[alexcrichton]

I've opened #3124 about upgrading Cargo's version of semver