Check Cargo.lock in version control for libraries

[tiziano88]

Describe the problem you are trying to solve

The official FAQ and various other places strongly suggest (almost mandate) that libraries do not check in Cargo.lock. This serves so that if the library is used as a dependency from another crate, the parent crate should get to decide what particular versions of dependencies to use for itself and all its transitive dependencies, respecting versioning restrictions indicated in the relevant Cargo.toml files.

Describe the solution you'd like

• strongly suggest versioning Cargo.lock in version control even for libraries; without this, it is practically impossible to achieve reproducibility of builds, tests and CI pipelines: the same exact version (commit checksum) of a library may compile / pass at some point in time on someone's machine, but spuriously break / fail later on or on some other machine, just because some dependency published a new version on crates.io
• add an option to cargo to skip packaging the local Cargo.lock when publishing a library to crates.io (by default it will exclude it for libraries and include it for binaries)
  • perhaps it is sufficient to manually exclude Cargo.lock from a package until this is implemented
• suggest relying on https://dependabot.com/rust/ or manually bumping dependencies in order to detect incompatibilities with new version of dependent crates in an automated way that is tracked under version control and maintains the hermeticity and reproducibility of builds, even for libraries

Notes

[Eh2406]

Just to be clere a libraries Cargo.lock has no effect on resolution for a project that depends on that library. That is true if the library does not commit its Cargo.lock, and it is true if it commits it but does not include it when publishing, and it is true even if it ends up in the final published artifact. If you commit your Cargo.lock, so your CI is not broken by some new version on crates.io, then the first you will hear about the brokege is from your users.

Whether it is better to have flakey but real test in CI or to have reliable but mocked tests in CI, really depends on the priorities of the library. It is not so different from every other time a project considers using mock objects. Do you call that other microservice, then you will now fast if they broke their api but tests will be flakey, or do you mock it so you have fast reliable test of what that microservice used to respond.

[ehuss]

I think it would be fine to add some more details to the documentation. There's a tradeoff, if Cargo.lock is included in source control, you'll likely be testing out-of-date dependencies. That's good for reproducibility as you say, but is bad because you won't quickly catch problems with new dependencies. If you have the CI budget, you can of course test both with Cargo.lock, and with the latest versions (by calling cargo update && cargo test).

[tiziano88]

Catching problems with new dependencies should not happen when someone is trying to test an unrelated change. Which often results in a new dependency breaking CI, which prevents even other, unrelated changes from going through.

dependabot (or something similar) seems the ideal solution to me, since it guarantees deterministic and hermetic CI, while at the same time allowing testing against new dependencies, in their own PR, so that if there is any issue after the fact it is also easy to narrow it down to the specific commit that introduced the new dependency version.

cargo update && cargo test has again reproducibility issues, since the result of cargo update depends on the exact point in time at which it is run.

[epage]

Another reason to revisit this decision is interest in MSRV testing. Until we have a minimal versions resolver feature stablized, the lockfile is the easiest way to emulate it when verifying MSRV in libraries.