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

Question

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

如果我理解正确，当我将 Cargo.lock 提交到我的 crate（它既是一个库又是一个可执行文件）的存储库中，并且将它发布到 crates.io 时，下游 crates 将忽略它并构建它自己的 snap，对吧?

Answer 1

是的，依赖于您的库的板条箱将忽略您的Cargo.lock. 货物常见问题解答提供了更多详细信息：

\n

\n

为什么二进制文件有Cargo.lock版本控制，但库没有？

\n

a 的目的Cargo.lock是描述成功构建时\n的世界状态。然后，通过确保编译完全相同的依赖项，它可用于在构建包的任何计算机上提供确定性构建。

\n

位于依赖链（二进制文件）最末端的应用程序和包最需要此属性。因此，建议\n所有二进制文件签入其Cargo.lock.

\n

对于图书馆来说，情况有些不同。库不仅由库开发人员使用，而且还由该库的任何下游使用者使用。依赖于该库的用户将不会检查该库\xe2\x80\x99s Cargo.lock（即使它\n存在）。这正是因为不应该为该库的所有用户确定性地\n重新编译该库。

\n

如果一个库最终被多个依赖项传递使用，则\xe2\x80\x99s\n可能只需要该库的单个副本（基于 semver\n兼容性）。如果 Cargo 使用了所有依赖项Cargo.lock文件，则可能会使用该库的多个副本，甚至可能会出现版本冲突。

\n

换句话说，库为其依赖项指定了 semver 要求，但无法看到完整情况。只有二​​进制文件等最终产品才有完整的\n图片来决定应使用哪些版本的依赖项。

\n

\n

Answer 2

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