Cargo.lock should be included in git

[booxter]

Describe the issue as clearly as possible:

https://doc.rust-lang.org/cargo/faq.html#why-have-cargolock-in-version-control

The missing file makes packaging harder, specifically in NixOS where the file is required to be present during the build.

Steps/code to reproduce the bug:

.

Expected result:

.

Error message:

Outlines/Python version information:

Version information

``` (command output here) ```

Context for the issue:

No response

[danieldk]

Also see NixOS/nixpkgs#357313 .

[torymur]

For a very long time the official recommendation was:
https://doc.rust-lang.org/1.71.1/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries

Why do binaries have Cargo.lock in version control, but not libraries?
The purpose of a Cargo.lock lockfile is to describe the state of the world at the time of a successful build. Cargo uses the lockfile to provide deterministic builds on different times and different systems, by ensuring that the exact same dependencies and versions are used as when the Cargo.lock file was originally generated.

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.

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). 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). 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.

In other words, libraries specify SemVer requirements for their dependencies but cannot see the full picture. Only end products like binaries have a full picture to decide what versions of dependencies should be used.

In August 2023 there was an update on the topic, which at least hints that there is no easy should be answer:
https://blog.rust-lang.org/2023/08/29/committing-lockfiles.html

For years, the Cargo team has encouraged Rust developers to commit their Cargo.lock file for packages with binaries but not libraries. We now recommend people do what is best for their project.

Insightful discussions around this: rust-lang/cargo#8728

This topic is complex and has misc pros and cons both ways. As this project develops it will be under consideration, but for now closing it.