2

例如，我使用barbarers crate：

barcoders = {version = "0.10.0", features = ["image",]}

是否可以指定此依赖项应使用哪个版本的图像？

就像是

barcoders = {version = "0.10.0", features = ["image=0.22.3",]}

因为它使用 image crate 版本0.18.0并且在我的项目中我使用 latest 0.22.3.

这是否意味着只有两种方法可以解决这个问题：

  1. 我在我的包中降级版本
  2. 条码器依赖得到更新
4

2 回答 2

2

不，无法为依赖项的（可选）依赖项指定版本。这是有道理的，因为您的依赖项仅针对他们在Cargo.toml. 在这种情况下，您所做的一切似乎都使用开源，您可以 fork barcoders，更新依赖项，运行测试套件，如果通过，请使用您的 fork。在这种情况下打开一个问题也是有礼貌的。

如果barcoders不是开源的，所以你不能分叉它，你最好的选择是切换到使用的image版本barcoders。如果您的 crate 是一个库，那么公开一个使用过时库的公共接口可能会很烦人，但这就是生活。这个问题的“正确”解决方案是等到图像1.0发布，这基本上是一个向前兼容的承诺，然后barcoders可以指定image = "^1"（即> = 1.0.0 <2.0.0）。我提到这个“解决方案”只是因为您似乎对 具有提交权限barcoders，实际上您通过image更新barcoders.

正如其中一条评论指出的那样，这个版本的兼容性问题并不像最初看起来那样脆弱。只要来自某些依赖包的不同版本的类型不跨越 api 边界，您的项目就可以同时包含该依赖项的任意数量的版本。使用多个版本的库需要 rust 团队在名称修饰方面的一些工作，您可以在此处阅读

于 2019-11-28T05:00:04.687 回答
0

不，你不能，也不应该，也不应该担心。

库是在一个时间点开发的，使用具有特定 API 的依赖项。依赖关系可能会改变主要版本之间的一些依赖关系（改变函数返回的类型，暴露不同的模式，等等）。这可能使其无法再编译。要真正更新某些内容，您可能需要首先更改使用依赖项的部分代码。

这是开源世界，因此您可以这样做并在原始 crate 中发布拉取请求以进行更新。这可能会受到赞赏，但不要低估这样做时需要注意不要自己打破其他人的板条箱。或者制作你自己的 crate 分支，只为你更新它。

但是您可能只是担心在编译期间看到具有不同版本的相同 crate 的重复项。Cargo 确实使用不同的版本进行编译，因此对依赖的 crate 的所有调用都将收到开发人员在编写它时所期望的内容。这在性能或最终以二进制形式出现的指令数量上都不是问题。别担心了。

于 2019-11-28T05:21:27.103 回答