Cargo: Should Cargo.lock be committed, or added to .gitignore?

[zr40]

There doesn't appear to be any documentation about the purpose of Cargo.lock and guidelines for handling it.

Should Cargo.lock be committed to a project's repository, or should it be added to .gitignore?

/cc nickel-org/nickel.rs#50

[alexchandel]

I heard on IRC it should be ignored for libraries, tracked for binaries.

[alexcrichton]

Yes, libraries should ignore Cargo.lock but binaries/applications should check-in Cargo.lock.

I believe @wycats is going to work on some documentation for this in the coming days.

[SimonSapin]

If Cargo.lock has meaningful content (as opposed to being a way to multiple instances of Cargo to run simultaneously), shouldn’t it be named something else?

[alexcrichton]

This is now documented, so I'm going to close this.

[heyman]

The documentation seems to reside on a new subdomain. The information regarding Cargo can now be found at: http://doc.crates.io/guide.html#cargo.toml-vs-cargo.lock

[AndreasHassing]

The answer in this FAQ describes the reasoning really well: http://doc.crates.io/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries

Just leaving this here, as Google'ing for "Crate.lock gitignore" leads to this issue, and @alexcrichton's link is dead.

[montao]

This is now documented, so I'm going to close this.

Link does not work. Maybe it is this now https://doc.rust-lang.org/cargo/guide/

[Markel]

Actually, right now the link is this one https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html. Here is the answer to the question:

If you’re building a non-end product, such as a rust library that other rust packages will depend on, put Cargo.lock in your .gitignore. If you’re building an end product, which are executable like command-line tool or an application, or a system library with crate-type of staticlib or cdylib, check Cargo.lock into git.

[gorakhargosh]

What if you're using Bazel and a mono-repo that has both libraries and binaries?