Can't specify precise crate version if there are multiple versions

[jethrogb]

# depcrate/Cargo.toml 
[package]
name = "depcrate"
version = "0.1.0"

[dependencies]
spin = "0.3.5"

# maincrate/Cargo.toml
[package]
name = "maincrate"
version = "0.1.0"

[dependencies]
spin = "0.4.0"
depcrate = { path = "../depcrate" }

A cargo build will result in getting spin versions 0.3.5 and 0.4.2. Now, because of a bug, I'd like to downgrade 0.4.2 to 0.4.0. Let's try this:

$cargo update -p spin --precise 0.4.0
error: There are multiple `spin` packages in your project, and the specification `spin` is ambiguous.
Please re-run this command with `-p <spec>` where `<spec>` is one of the following:
  spin:0.4.2
  spin:0.3.5

Well ok, that makes sense. So let's specify spin:0.4.2:

$cargo update -p spin:0.4.2 --precise 0.4.0
    Updating registry `https://github.com/rust-lang/crates.io-index`
error: no matching package named `spin` found (required by `depcrate`)
location searched: registry https://github.com/rust-lang/crates.io-index
version required: = 0.3.5
versions found: 0.4.0

I thought I just said to only touch 0.4.2?

When I manually edit Cargo.lock and change all occurences of 0.4.2 to 0.4.0, it builds fine.

[alexcrichton]

Oh dear this looks like it's an unfortunate interaction with how --precise is implemented currently. Whenever --precise is passed with a registry source (like this) the precise version gets encoded in the SourceId "precise" field which is then later read when returning matching packages for a dependency query. Unfortunately when we read the second time we unknowningly also return only the precise version for the unrelated query of 0.3.5.

In other words, definitely a bug! In theory shouldn't be too hard to fix though.

[alexcrichton]

Ok, thinking a bit more, I think the easiest solution here is basically to keep the local hack for now and encode a bit more information. So right now we encode $name=$precise where if you say cargo update -p foo --precise 0.3.4 we'll encode a precise field of foo=0.3.4.

In scope, however, we have the actual dependency with the concrete version, so I think that we want to instead encode the previous version as well as the target precise version. That is if you previously had foo at 0.3.2 the previous command would serialize to something like foo=0.3.2->0.3.4.

Later on when we actually read out this encoding (which yes is a hack but oh well) I think we'll just want to extract the two fields (0.3.2 and 0.3.4) above. We only return the precise 0.3.4 target if the version requirement matches the previous one. That is, if we see a dependency for 0.2.0 then we won't return 0.3.4 as a matching package because 0.2.0 doesn't match 0.3.2.

I'm gonna tag this as E-easy but it's a little harder than what it would normally be. Please feel free to ask lots of question as this is a bit into the guts of Cargo, but I think what I outlined above should do the trick!

[jethrogb]

That is if you previously had foo at 0.3.2 the previous command would serialize to something like foo=0.3.2->0.3.4.

Remember that a version can be more than just numbers separated by periods: http://semver.org/spec/v2.0.0.html . But it looks like anything besides [0-9A-Za-z.-+] is ok for encoding separators.

[alexcrichton]

Ah good point, and of course if someone's working on this and otherwise sees a better way to transmit this information, that would also be perfectly acceptable as well!

[roysc]

Any workarounds for this as it is now?

[jethrogb]

@roysc2 Workaround is manually edit Cargo.lock

[gibix]

Hello, I'm working on the solution proposed by @alexcrichton as my first rust/cargo contribution. I'm also looking if is possible to change the resover in order to accept a list of -=[version contraints].

[alexcrichton]

@gibix nice! Lemme know if you need any help!