-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Comments
cargo publish
forces non-compatible semver updates for version ranges in dependencies
This sounds like it's boiling down to #2064, but do you think this is a separate issue? |
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. |
I think I'm running into this too... I don't understand why |
Oh wait, just found #2263, I think that's my real problem |
I'm trying to publish a new version of
multipart-nickel
to update itsmultipart
dependency, which is now using a version range forhyper = ">=0.9.0, < 0.11"
. However,multipart-nickel
requireshyper = "0.9.18"
because Nickel is still on that version.This works fine for
cargo build
andcargo test
, the dependency solver works this out just fine and useshyper = 0.9.18
formultipart
. However, when I go to publishmultipart-nickel
, the publish test run forces a non-compatible upgrade tohyper = 0.10.9
(secondCargo.lock
istarget/package/multipart-nickel-0.3.0/Cargo.lock
): https://gist.github.com/abonander/332fa65592fd0e593e767834d09eb96f#file-multipart-nickel-0-3-0-cargo-lock-L99This, 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 ownCargo.lock
.The text was updated successfully, but these errors were encountered: