解析包版本时，我可以强制使用依赖项的 Cargo.lock 吗? [英] Can I force the use of my dependencies' Cargo.lock when resolving package versions?

问题描述

Cargo FAQ 指出 Cargo.lock 不用于库，而是使用 Cargo.toml 中的依赖版本范围，以减少共享依赖项之间的 lib 重复.

但是，我认为在某些情况下，最好使用已知的成功构建的 lib 依赖项.即，当依赖项由于更新其自己的依赖项而不再构建时.

是否可以将 Cargo 配置为支持库的 Cargo.lock，而不是 Cargo.toml(如果可用)?最好按包装进行.

<小时>

(更新:下面的问题已经在wither 0.5.1中修复，现在依赖是mongodb = "0.10.*".但是，似乎如果 mongodb 更新其 bson 依赖项，此问题将再次出现 - 至少直到再次更新 wither 的依赖项以匹配为止.或者，正如@Shepmaster 在他的回答中提到的那样，直到 RFC 1977 已实施.)

我的特殊情况是尝试使用包 wither 0.5.0:

• wither 的 Cargo.toml 指定依赖 mongodb = "<1.0" 和 bson = "<1.0"
• mongodb 的 Cargo.toml 指定 bson = "0.10.0"
• bson 的最新版本是 0.11.1

无需进一步配置依赖，bson 0.10.0用于mongodb，bson 0.11.1用于wither.这会导致 wither 的编译失败，因为它使用了 bson 中的一些结构与 mongodb 进行交互.

我目前的解决方法是在本地克隆一个 wither 副本，并使用一个经过编辑的 Cargo.toml 来修复它的 bson 版本.但是，git 存储库 包含一个已提交的 Cargo.lock，这将允许我至少要使用这个存储库作为我的依赖目标，而不是自己克隆和修改包.

解决方案

不，您不能使用库的 Cargo.lock.

<块引用>

因为它使用了 bson 的一些结构来与 mongodb 进行交互.

这是根本问题.目前，依赖解析器不知道一个 crate 在公共接口中暴露了另一个 crate 的类型.这将在 RFC 1977 已实施.

如合并货物依赖项中所述，您可以微调要合并的依赖项的版本:

cargo update -p bson:0.11.1 --precise 0.10.0

另见:

• 整合货物依赖
• 在 Cargo.toml 或 Cargo.lock 中设置项目依赖的特定版本的依赖

<小时>

话虽如此，因为 semver，您的代码运行良好:

[依赖项]凋零 = "0.5.1"mongodb =0.3.7"

$ cargo tree --invert -p bsonbson v0.10.0├── mongodb v0.3.7│ ├── example v0.1.0 (file:///private/tmp/example)│ └── 凋零 v0.5.1│ └── 例子 v0.1.0 (file:///private/tmp/example) (*)

<块引用>

貌似不可避免，mongodb使用bson 0.10.0，wither使用bson 0.11.1.

事实并非如此，您可以从 (a) 上面的示例和 (b) 您自己关于可接受版本范围的声明中看出这一点.

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.

解决方案

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.

这篇关于解析包版本时，我可以强制使用依赖项的 Cargo.lock 吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！