New library template gitignores Cargo.lock

[Vlad-Shcherbina]

Problem

The .gitignore file in the new library template lists the Cargo.lock file. This can make it more difficult to reproduce builds and perform bisections using the git bisect command.

Steps

1. Run cargo new --bin my_app to create a new binary crate.
2. Run cargo new --lib my_lib to create a new library crate.

The .gitignore file in my_app does not list Cargo.lock, but the .gitignore file in my_lib does.

Possible Solution(s)

The new library crate template shouldn't add Cargo.lock to .gitignore, same as the new binary crate template.

Notes

Including the Cargo.lock file in the repository can improve the developer experience by making it more likely that the library will compile when running git clone and cargo check.

It is also a question orthogonal to that of including Cargo.lock in the packaged crate. Even if Cargo.lock is not used during dependency resolution, it can still be useful to have in the repository for the purposes of reproducibility and hermeticity when developing the library itself.

Version

cargo 1.68.0-nightly (cc0a32087 2022-12-14)                                                                                                 release: 1.68.0-nightly
commit-hash: cc0a320879c17207bbfb96b5d778e28a2c62030d
commit-date: 2022-12-14
host: x86_64-pc-windows-msvc
libgit2: 1.5.0 (sys:0.15.0 vendored)
libcurl: 7.86.0-DEV (sys:0.4.59+curl-7.86.0 vendored ssl:Schannel)                                                                          os: Windows 10.0.19044 (Windows 10 Pro) [64-bit]

[Rustin170506]

This is by design, you can check out https://doc.rust-lang.org/stable/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries.

[Vlad-Shcherbina]

I'm aware of this argument and mentioned it in the notes.

It is true that Cargo.lock won't help to build the library in the exact same configuration as it will be built by some application that uses it, and that's fine.

However, it will help to build the library itself (and associated items like tests and examples) in a known configuration. This is useful for the purpose of developing the library itself.

Suppose I made a library and published it on GitHub. You check it out and try to build it and run tests. It works on my machine and doesn't work on yours, because your Cargo.lock was generated at a different time. This is bad development experience.

It could be argued that this shouldn't happen in a correct library. A correct library is supposed to work for all combinations of dependency versions compatible with the constraints specified in Cargo.toml. However, in real life, libraries are merely approximately correct. Sometimes the constraints are not tight enough, or the dependencies break SemVer requirements. A principled approach would be to build and test the library with various Cargo.lock files, preferably with ALL possible Cargo.lock files. But this isn't practical. Building and testing with one specific Cargo.lock file is better than building and testing with an arbitrary Cargo.lock file thatmay be different for each developer and could change over time uncontrollably (that's what you get by not keeping Cargo.lock under version control).

[weihanglo]

Thanks for the report. This has been discussed a couple of times. Probably a duplicate of #8728 or #4353?

[weihanglo]

I will go ahead closing this. If anyone feels it's wrong, feel free to commment. We can then consider re-open.