Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cargo publish forces non-compatible semver updates for version ranges in dependencies #3933

Closed
abonander opened this issue Apr 19, 2017 · 5 comments

Comments

@abonander
Copy link

abonander commented Apr 19, 2017

I'm trying to publish a new version of multipart-nickel to update its multipart dependency, which is now using a version range for hyper = ">=0.9.0, < 0.11". However, multipart-nickel requires hyper = "0.9.18" because Nickel is still on that version.

This works fine for cargo build and cargo test, the dependency solver works this out just fine and uses hyper = 0.9.18 for multipart. However, when I go to publish multipart-nickel, the publish test run forces a non-compatible upgrade to hyper = 0.10.9 (second Cargo.lock is target/package/multipart-nickel-0.3.0/Cargo.lock): https://gist.github.com/abonander/332fa65592fd0e593e767834d09eb96f#file-multipart-nickel-0-3-0-cargo-lock-L99

This, obviously, causes the publish to fail because the version of Hyper that it is trying to use is incompatible with the one that Nickel is using and the library fails to compile. This is a really unintuitive discrepancy that doesn't really make sense in practice. I spent [longer than I'd like to admit] trying to make this work because I thought I'd declared the wrong version somewhere, but I didn't know that cargo publish uses its own Cargo.lock.

@abonander abonander changed the title Cargo publish forces non-compatible semver updates for version ranges in dependencies cargo publish forces non-compatible semver updates for version ranges in dependencies Apr 19, 2017
@alexcrichton
Copy link
Member

This sounds like it's boiling down to #2064, but do you think this is a separate issue?

@abonander
Copy link
Author

It sounds like it has a simpler solution than #2064, as it's mainly about the discrepancy in dependency solving between cargo publish and the other commands, but fixing #2064 may well fix this.

@alexcrichton
Copy link
Member

Ok, in that case I'm going to close this in #2064. What I believe you're seeing here is nondeterminism in graph resolution. Some invocations of Cargo will pick everything as 0.9 whereas others will have the 0.9 / 0.10 split. With #2064 Cargo will have a hard constraint which guarantees 0.9 everywhere.

@carols10cents
Copy link
Member

I think I'm running into this too... I don't understand why cargo publish is resolving dependencies again, I have a Cargo.lock, shouldn't it just use that?

@carols10cents
Copy link
Member

Oh wait, just found #2263, I think that's my real problem

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants