我有一个项目，它具有依赖于iron >= 0.3, <= 0.4的依赖项（cookie实用程序）。
我的项目依赖于铁0.3（因此我可以使用尚未更新到最新版铁的router中间件。）
当我尝试编译我的项目时，cookie实用程序会拉出0.4版本的铁，并且由于使用了不同版本的铁，我会收到错误。
但是，我可以这样做：
cargo update -p <cookie utility>
（通常）改变该包对铁的依赖性以匹配我正在使用的铁，并消除对铁0.4的无关依赖。 （奇怪的是，我有时必须在更新之前多次运行该命令。）
显然我无法指定依赖项的依赖项版本：Set specific version of the dependency of a project's dependency in Cargo.toml or Cargo.lock。
如果货物可以猜到我想要使用单一版本的铁，那将是很好的，但我明白为什么它不能。但是，我对cargo update -p <package>实际起作用的原因感到困惑;它会更新程序包的依赖关系似乎是不直观的。
我想我的第一个真正的问题是：我如何指定依赖项的依赖项版本（当且仅当我想要的版本在该库的受支持版本范围内时）？我不认为上面提到的问题中提出的解决方案是理想的。我觉得如果Cargo能够很好地支持这一点会更好，因此库可以将其依赖版本范围保持为开放状态，因为它们的功能允许。
与此同时，我发现了这个＆＃34;技巧＆＃34;这似乎做我想要的（cargo update -p <pkg>）。我看起来并不是很难，但这种行为似乎并没有在任何明显的地方被描述过。我的第二个问题是：这是一种合并依赖关系的有效方法吗？我有什么地方可以找到更多相关信息吗？
重现步骤：
cargo new --bin ironapp; cd ironapp。cargo new cookie_util。cookie_util/Cargo.toml中添加一个依赖项：iron = ">= 0.3, <= 0.4"。Cargo.toml中添加两个依赖项：iron = "0.3.0"和cookie_util = { path = "cookie_util"}。cargo build。确认Cargo.lock。cargo update -p cookie_util。最终它将删除对iron 0.4.0的依赖。我刚刚在rustc-1.10.0 / cargo-0.11.0上测试了这个。我确保在第1步开始时target和Cargo.lock都不存在。
答案 0 :(得分：5)
通过阅读cargo/issues/2064的评论，我意识到解决这些类型的依赖关系的更强大的方法是使用--precise标志。就我的例子而言，
cargo update -p iron:0.4.0 --precise 0.3.0
删除不必要的依赖项。这需要人们深入研究Cargo.lock并手动确定依赖关系可以收敛的位置，但要比运行cargo update -p <pkg>并希望最好，或者手动编辑Cargo.lock要好得多。