Is it _Wrong_ To Have a Cargo.lock in a Library Crate

So I have read the Cargo FAQ and I completely undestand the reasoning on why you don't track the Cargo.lock in libraries, but does it cause problems? It doesn't right? The Cargo.lock of libraries are completely ignored by Cargo correct?

Here's why I want to track my Cargo.lock in my library crate. Even though I don't want the Cargo.lock to effect the people who depend on my library, I do want the Cargo.lock so that I can lock the working version of the library for my library examples.

For example, I've got a library that I just did a git bisect on. I checked out an old version of the library and it won't compile because I was using a Git dependency without a locked revision. I know, maybe not the best idea, but the library is moving fast right now and updating the git ref manually in the Cargo.toml is not practical. I've done the same thing in a bin crate and I had the advantage of commiting the Cargo.lock so that even though I'm using a git dependency, the Cargo.lock will keep track of which commit worked for me! It's really cool actually.

So, while in most cases commiting the Cargo.lock doesn't make sense in a library, I think it makes sense in this edge case and want to know whether or not it will cause problems if I do.

No, using Cargo.lock for libraries is not wrong, feel free to do it if you find that helpful for whatever reason.

A (somewhat) common pattern is two run CI for

  • the latest stable Rust without Cargo.lock (to catch upstream regressions)
  • the MSRV version of Rust with Cargo.lock (to make sure that the library itself doesn't break MSRV, while keeping MSRV of upstream crates pinned)
5 Likes

Perfect, thanks! :tada: :slight_smile: