整合货物依赖 [英] Consolidating cargo dependencies
问题描述
我有一个依赖于 iron >= 0.3, <= 0.4
.
我的项目依赖于 Iron 0.3
(所以我可以使用尚未更新到最新 Iron 的 router
中间件).
My project has a dependency on iron 0.3
(so I can use the router
middleware that hasn't yet been updated to the latest iron).
当我尝试编译我的项目时,cookie 实用程序会提取 0.4
版本的铁,并且由于使用了不同版本的铁,我收到错误.
When I try to compile my project, the cookie utility pulls the 0.4
version of iron, and I get errors since different versions of iron are being used.
但是,我可以:
cargo update -p <cookie utility>
这(通常)改变了该包对铁的依赖以匹配我正在使用的那个,并删除对铁0.4
的额外依赖.(奇怪的是,我有时必须在该命令更新之前运行几次.)
which (usually) changes that package's dependency on iron to match the one I am using, and removes the extraneous dependency on iron 0.4
. (Bizarrely, I sometimes have to run that command a couple of times before it updates.)
显然我无法指定依赖项的依赖项版本:在 Cargo.toml 或 Cargo.lock 中设置项目依赖的特定版本的依赖.
Apparently I can't specify the dependency version of a dependency: Set specific version of the dependency of a project's dependency in Cargo.toml or Cargo.lock.
如果货物能猜到我想使用单一版本的铁就好了,但我明白为什么不能.但是,我对 cargo update -p
实际工作的原因感到困惑;它会更新包的依赖项似乎不直观.
It would be nice if cargo could guess that I want to use a single version of iron, but I understand why it can't. However, I'm confused about why cargo update -p <package>
actually works; it seems non-intuitive that it would update a dependency for the package.
我想我的第一个真正的问题是:如何指定依赖项的依赖项版本(何时且仅当我想要的版本在该库支持的版本范围内时)?我不认为上面链接的问题中建议的解决方案是理想的.我觉得如果 Cargo 能够很好地支持这一点会更好,这样库就可以在其功能允许的情况下保持其依赖版本范围尽可能开放.
I guess my first real question is: how can I specify the dependency versions of dependencies (when and only when the version I want is within the supported version range of that library)? I don't think the solutions suggested in the question linked above are ideal. I feel like it would be better if Cargo could support this well, so that libraries could leave their dependency version ranges as open as their functionality allows.
同时,我发现了这个似乎可以做我想做的技巧"(cargo update -p
).我看起来不是很努力,但这种行为似乎没有在任何明显的地方描述.我的第二个问题是:这是合并依赖项的有效方法吗?有什么地方可以找到更多相关信息吗?
At the same time, I found this "trick" that seems to do what I want (cargo update -p <pkg>
). I haven't looked super hard, but this behavior doesn't seem to be described in any obvious place. My second question is: is this a valid way to coalesce dependencies? Is there any place I can find more information about this?
以及重现步骤:
- 新建一个项目:
cargo new --bin Ironapp
;cd ironapp
. - 创建 cookie 依赖项:
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.lock
中需要两个版本的铁.- 运行
cargo update -p cookie_util
1 到 4 次(或更多)次.最终它将消除对iron 0.4.0
的依赖.
- Create a new project:
cargo new --bin ironapp
;cd ironapp
. - Create the cookie dependency:
cargo new cookie_util
. - In
cookie_util/Cargo.toml
add one dependency:iron = ">= 0.3, <= 0.4"
. - In
Cargo.toml
add two dependencies:iron = "0.3.0"
andcookie_util = { path = "cookie_util"}
. cargo build
. Confirm that two versions of iron are required inCargo.lock
.- Run
cargo update -p cookie_util
anywhere between 1 and 4 (or more) times. Eventually it will remove the dependency oniron 0.4.0
.
我刚刚在 rustc-1.10.0/cargo-0.11.0 上测试了这个.我确保 target
和 Cargo.lock
在第 1 步开始时都不存在.
I just tested this on rustc-1.10.0/cargo-0.11.0. I made sure target
and Cargo.lock
were both absent at the start of step 1.
推荐答案
通读 cargo/issues/2064,我意识到解决这些类型依赖关系的更可靠方法是使用 --precise
标志.对于我的例子,
Reading through the comments of cargo/issues/2064, I realized that a more robust way of resolving these types of dependencies is to use the --precise
flag. For my example,
cargo update -p iron:0.4.0 --precise 0.3.0
移除不必要的依赖.这需要深入研究 Cargo.lock
并手动确定依赖项可以收敛的位置,但这比运行 cargo update -p
并希望获得最佳效果要好得多,或手动编辑Cargo.lock
.
removes the unnecessary dependency. This requires one to dig into Cargo.lock
and manually determine where dependencies can converge, but is far better than running cargo update -p <pkg>
and hoping for the best, or manually editing Cargo.lock
.
这篇关于整合货物依赖的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!