Can I force the use of my dependencies' Cargo.lock when resolving package versions?

问题

The Cargo FAQ states that Cargo.lock is not used for libraries, instead using dependency version ranges found in Cargo.toml, to reduce lib duplication among shared dependencies.

However, I think there are instances where using a known successful build of a lib dependency is preferable. Namely, when a dependency no longer builds due to updates of its own dependencies.

Is it possible to configure Cargo to favour a library's Cargo.lock, over Cargo.toml, if it's available? Preferably on a by-package basis.

---

(Update: the issue below has been fixed in wither 0.5.1, where the dependency is now mongodb = "0.10.*". However, it seems that this issue would re-appear if mongodb updates its bson dependency - at least until wither's dependencies are updated once again to match. Or, as @Shepmaster mentions in his answer, until RFC 1977 is implemented.)

My particular situation is trying to use the package wither 0.5.0:

• wither's Cargo.toml specifies dependencies mongodb = "<1.0" and bson = "<1.0"
• mongodb's Cargo.toml specifies bson = "0.10.0"
• bson's latest version is at 0.11.1

Without configuring dependencies further, bson 0.10.0 is used for mongodb, and bson 0.11.1 is used for wither. This causes compilation of wither to fail, as it uses some structures from bson to interact with mongodb.

My current workaround is a locally-cloned copy of wither, with an edited Cargo.toml to fix its version of bson. However, the git repository includes a committed Cargo.lock, which would allow me at least to use this repository as my dependency target, rather than cloning and modifying the package myself.

回答1:

No, you cannot use a library's Cargo.lock.

as it uses some structures from bson to interact with mongodb.

This is the root problem. Currently, it's unknown to the dependency resolver that one crate has exposed another crate's types in a public interface. That will be addressed when RFC 1977 is implemented.

As described in Consolidating cargo dependencies, you can nudge the version of the dependency to be consolidated:

cargo update -p bson:0.11.1 --precise 0.10.0

See also:

• Consolidating cargo dependencies
• Set specific version of the dependency of a project's dependency in Cargo.toml or Cargo.lock

---

That being said, because of semver, your code works just fine:

[dependencies]
wither = "0.5.1"
mongodb = "0.3.7"

$ cargo tree --invert -p bson
bson v0.10.0
├── mongodb v0.3.7
│   ├── example v0.1.0 (file:///private/tmp/example)
│   └── wither v0.5.1
│       └── example v0.1.0 (file:///private/tmp/example) (*)

Seemingly unavoidably, bson 0.10.0 is used for mongodb, and bson 0.11.1 is used for wither.

This is not the case, as you can tell by (a) the example above and (b) your own statements about the acceptable version ranges.

来源：https://stackoverflow.com/questions/49723779/can-i-force-the-use-of-my-dependencies-cargo-lock-when-resolving-package-versio