简体繁体 English

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

[英]Should Cargo.lock be committed when the crate is both a rust library and an executable?

原文 2020-07-12 13:20:32 1 2 rust/ rust-cargo/ rust-crates

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

If I understand correctly, when I commit Cargo.lock into my crate (which is both a library and an executable)'s repository, and also, publish it to crates.io, downstream crates will ignore it and build it's own snap, right?如果我理解正确，当我将 Cargo.lock 提交到我的 crate（它既是一个库又是一个可执行文件）的存储库中，并将它发布到 crates.io 时，下游 crate 将忽略它并构建它自己的快照，对?

2 个解决方案

I found the best practice from the excellent project ripgrep , which split's itself into several crates .我从优秀的项目ripgrep中找到了最佳实践，该项目将自身拆分为几个 crate 。 For the binary crate in the root, they track Cargo.lock, but for library crates that provide functionality for the application (for example, pcre2 ), they don't.对于根目录中的二进制 crate，它们跟踪 Cargo.lock，但对于为应用程序提供功能的库 crate（例如pcre2 ），它们不跟踪。

Yes, crates that depend on your library will ignore your Cargo.lock .是的，依赖于你的库的 crates 将忽略你的Cargo.lock 。 The Cargo FAQ provides more details :货物常见问题解答提供了更多详细信息：

Why do binaries have Cargo.lock in version control, but not libraries?为什么二进制文件在版本控制中有Cargo.lock ，但没有库？

The purpose of a Cargo.lock is to describe the state of the world at the time of a successful build. Cargo.lock的目的是描述成功构建时世界的 state。 It is then used to provide deterministic builds across whatever machine is building the package by ensuring that the exact same dependencies are being compiled.然后，通过确保正在编译完全相同的依赖项，它用于在构建 package 的任何机器上提供确定性构建。

This property is most desirable from applications and packages which are at the very end of the dependency chain (binaries).位于依赖链（二进制文件）最末端的应用程序和包最需要此属性。 As a result, it is recommended that all binaries check in their Cargo.lock .因此，建议所有二进制文件都签入它们的Cargo.lock 。

For libraries the situation is somewhat different.对于图书馆来说，情况有些不同。 A library is not only used by the library developers, but also any downstream consumers of the library.库不仅供库开发人员使用，也供库的任何下游消费者使用。 Users dependent on the library will not inspect the library's Cargo.lock (even if it exists).依赖于库的用户不会检查库的Cargo.lock （即使它存在）。 This is precisely because a library should not be deterministically recompiled for all users of the library.这正是因为不应为库的所有用户确定性地重新编译库。

If a library ends up being used transitively by several dependencies, it's likely that just a single copy of the library is desired (based on semver compatibility).如果一个库最终被多个依赖项传递使用，则可能只需要该库的一个副本（基于 semver 兼容性）。 If Cargo used all of the dependencies' Cargo.lock files, then multiple copies of the library could be used, and perhaps even a version conflict.如果 Cargo 使用了所有依赖项的Cargo.lock文件，则可以使用该库的多个副本，甚至可能会出现版本冲突。

In other words, libraries specify semver requirements for their dependencies but cannot see the full picture.换句话说，库为它们的依赖项指定了 semver 要求，但看不到全貌。 Only end products like binaries have a full picture to decide what versions of dependencies should be used.只有像二进制文件这样的最终产品才能完整地决定应该使用哪些版本的依赖项。