当 crate 既是 Rust 库又是可执行文件时，是否应该提交 Cargo.lock？

Question

我已阅读https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html

如果我理解正确的话，当我将 Cargo.lock 提交到我的板条箱（既是一个库也是一个可执行文件）的存储库中，并将其发布到 crates.io 时，下游板条箱将忽略它并构建它自己的快照，对吗？

Answer 1

是的，依赖于您的库的板条箱将忽略您的

Cargo.lock

。货物常见问题解答提供了更多详细信息：

为什么二进制文件在版本控制中有

Cargo.lock

，而库则没有？

Cargo.lock

的目的是描述当时世界的状态 成功构建的。然后它被用来提供跨领域的确定性构建 无论机器通过确保完全相同来构建包 正在编译依赖项。

此属性对于位于以下位置的应用程序和包来说是最理想的： 依赖链（二进制文件）的最末端。因此，建议 所有二进制文件都检查其

Cargo.lock

。

对于图书馆来说，情况有些不同。图书馆不仅被使用 库开发者，还有库的任何下游消费者。用户 依赖于库不会检查库的

Cargo.lock

（即使它 存在）。这正是因为库不应该是确定性的 为库的所有用户重新编译。 如果一个库最终被多个依赖项传递使用，那么它是 可能只需要该库的一个副本（基于 semver 兼容性）。如果 Cargo 使用了所有依赖项的

Cargo.lock

文件， 那么可以使用该库的多个副本，甚至可能是一个版本 冲突。

换句话说，库为其依赖项指定了 semver 要求，但是 看不到全貌。只有像二进制文件这样的最终产品才具有完整的 图片来决定应该使用什么版本的依赖项。

Answer 2

ripgrep

中找到了最佳实践，它将自己分成了几个板条箱。对于根目录中的二进制 crate，它们会跟踪 Cargo.lock，但对于为应用程序提供功能的库 crate（例如，pcre2），它们不会跟踪。