Hey, I'm also interested in your argument against committing lockfiles.
My opinion is that all projects should always commit their lockfiles. The reason is reproducibility.
- A lockfile allows you to checkout any commit and be guaranteed that the dependencies will allow you to successfully compile the project (assuming the registry is immutable, which is the case for
crates.io). - A lockfile does not prevent you from checking what would happen with the latest dependencies: you can delete it at any time to force a refresh (or just use
cargo update). - On the other hand, if you don't commit the lockfile, it's virtually impossible to recover the state at the time of the commit.
In my opinion the benefits of long-term reproducible builds far outweigh the need to be explicit when you want to check behavior with the latest compatible dependencies. In particular they are invaluable when investigating regressions or trouble-shooting build errors. If a crate fails to build locally, but I see a commit with a lockfile and green CI it narrows down the source of errors to factors outside of the control of cargo.
To be honest I'm still a bit baffled by this recommendation in the cargo book:
Why do binaries have
Cargo.lockin version control, but not libraries?[...]
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.
A Cargo.lock in a lib repo is obviously not for users but for lib devs. A library still has binaries, they're just called through cargo test instead of cargo run; why should they be non-deterministic by default? A Cargo.lock does not prevent running your tests against the latest dependency versions, it's easy. What's hard is manually resolving the dependencies at a given time when you forgot to commit the lock file in the first place.
This is also the stance of Yarn, which is IMO the most reliable package manager for Node:
Which files should be gitignored?
[...]
yarn.lockshould always be stored within your repository (even if you develop a library).
Yarn actually goes even further and recommends storing the Yarn version itself in the project. I recommend also reading their arguments (they have other ones, such as a missing lock file not being sufficient to ensure you use the freshest dependencies anyway). cargo can piggyback off rust-version so we probably don't need a cargo-version.
Also to have a message on the topic of this thread. A few months ago I posted a comment about a previous version of cargo upgrade complaining that it was harder to pull the latest version to test against them. Since then, cargo-edit was updated a few times and I'm very happy with the current iteration of cargo upgrade. Thank you for your work.