我有一个项目,它具有依赖于铁 的依赖项(cookie实用程序)>= 0.3, <= 0.4.
我的项目依赖于铁0.3(所以我可以使用router尚未更新到最新铁的中间件).
当我尝试编译我的项目时,cookie实用程序会拉出0.4铁的版本,并且由于使用了不同版本的铁,我会收到错误.
但是,我可以这样做:
cargo update -p <cookie utility>
它(通常)改变了包对铁的依赖性以匹配我正在使用的铁,并消除了对铁的无关依赖0.4.(奇怪的是,我有时必须在更新前多次运行该命令.)
显然我无法指定依赖项的依赖项版本:在Cargo.toml或Cargo.lock中设置项目依赖项的依赖项的特定版本.
如果货物可以猜到我想要使用单一版本的铁,那将是很好的,但我明白为什么它不能.但是,我对为什么cargo update -p <package>实际起作用感到困惑; 它似乎不直观,它会更新包的依赖关系.
我想我的第一个真正的问题是:如何指定依赖项的依赖项版本(当且仅当我想要的版本在该库的受支持版本范围内时)？我不认为上面提到的问题中提出的解决方案是理想的.我觉得如果Cargo能够很好地支持这一点会更好,因此库可以将其依赖版本范围保持为功能允许的开放状态.
与此同时,我发现这个似乎做我想要的"技巧"(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_util1到4(或更多)次.最终它将删除依赖iron 0.4.0.我刚刚在rustc-1.10.0/cargo-0.11.0上进行了测试.我确定target并且Cargo.lock在第1步开始时都缺席了.
通过阅读cargo/issues/2064的评论,我意识到解决这些类型的依赖关系的更强大的方法是使用该--precise标志.就我的例子而言,
cargo update -p iron:0.4.0 --precise 0.3.0
消除不必要的依赖.这需要人们深入研究Cargo.lock并手动确定依赖关系可以收敛的位置,但要比运行cargo update -p <pkg>和希望最好,或手动编辑要好得多Cargo.lock.
| 归档时间： |
|
| 查看次数： |
510 次 |
| 最近记录： |