我已阅读https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html
如果我理解正确,当我将 Cargo.lock 提交到我的 crate(它既是一个库又是一个可执行文件)的存储库中,并将其发布到 crates.io 时,下游 crates 将忽略它并构建它自己的快照,对?
我已阅读https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html
如果我理解正确,当我将 Cargo.lock 提交到我的 crate(它既是一个库又是一个可执行文件)的存储库中,并将其发布到 crates.io 时,下游 crates 将忽略它并构建它自己的快照,对?
是的,依赖于你的库的 crates 将忽略你的Cargo.lock
. 货物常见问题解答提供了更多详细信息:
为什么二进制文件有
Cargo.lock
版本控制,而不是库?a 的目的
Cargo.lock
是描述成功构建时的世界状态。然后,通过确保正在编译完全相同的依赖项,它用于在任何正在构建包的机器上提供确定性构建。位于依赖链(二进制文件)最末端的应用程序和包最需要此属性。因此,建议所有二进制文件都签入它们的
Cargo.lock
.对于图书馆来说,情况有些不同。库不仅供库开发人员使用,也供库的任何下游消费者使用。依赖于该库的用户将不会检查该库
Cargo.lock
(即使它存在)。这正是因为不应为库的所有用户确定性地重新编译库。如果一个库最终被多个依赖项传递使用,则可能只需要该库的一个副本(基于 semver 兼容性)。如果 Cargo 使用了所有依赖项的
Cargo.lock
文件,则可以使用该库的多个副本,甚至可能会出现版本冲突。换句话说,库为它们的依赖项指定了 semver 要求,但看不到全貌。只有像二进制文件这样的最终产品才能完整地决定应该使用哪些版本的依赖项。
我从优秀的项目ripgrep中找到了最佳实践,该项目将自身拆分为几个 crate。对于根目录中的二进制 crate,它们跟踪 Cargo.lock,但对于为应用程序提供功能的库 crate(例如pcre2),它们不跟踪。