Should Cargo.lock be committed, or added to .gitignore? #315
Comments
|
I heard on IRC it should be ignored for libraries, tracked for binaries. |
|
Yes, libraries should ignore I believe @wycats is going to work on some documentation for this in the coming days. |
|
If |
|
This is now documented, so I'm going to close this. |
|
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 |
|
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 " |
Libraries should ignore `Cargo.lock`. See <rust-lang/cargo#315> and <http://doc.crates.io/guide.html>.
Libraries should ignore `Cargo.lock`. See <rust-lang/cargo#315> and <http://doc.crates.io/guide.html>.
According to [1], [2] Cargo.lock should be added to gitignore for libraries. [1](http://doc.crates.io/guide.html#cargo.toml-vs-cargo.lock) [2](rust-lang/cargo#315)
According to [1], [2] Cargo.lock should be added to gitignore for libraries. [1](http://doc.crates.io/guide.html#cargo.toml-vs-cargo.lock) [2](rust-lang/cargo#315)
According to [1], [2] Cargo.lock should be added to gitignore for libraries. [1](http://doc.crates.io/guide.html#cargo.toml-vs-cargo.lock) [2](rust-lang/cargo#315)
According to [1], [2] Cargo.lock should be added to gitignore for libraries. [1](http://doc.crates.io/guide.html#cargo.toml-vs-cargo.lock) [2](rust-lang/cargo#315)
According to [1], [2] Cargo.lock should be added to gitignore for libraries. [1](http://doc.crates.io/guide.html#cargo.toml-vs-cargo.lock) [2](rust-lang/cargo#315)
According to [1], [2] Cargo.lock should be added to gitignore for libraries. [1](http://doc.crates.io/guide.html#cargo.toml-vs-cargo.lock) [2](rust-lang/cargo#315)
Cargo.lock should be committed for binaries, see also rust-lang/cargo#315.
Link does not work. Maybe it is this now https://doc.rust-lang.org/cargo/guide/ |
To ensure reproducible builds for the compiled binaries it's recommended to add the `Cargo.lock` file to version control. Refs.: - Cargo Book FAQs: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries - Discussion in a github issue: rust-lang/cargo#315
To ensure reproducible builds for the compiled binaries it's recommended to add the `Cargo.lock` file to version control. Refs.: - Cargo Book FAQs: https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries - Discussion in a github issue: rust-lang/cargo#315
As per rust-lang/cargo#315 Signed-off-by: Matthew Fisher <matt.fisher@fermyon.com>
|
Cargo.lock not only specifies the specific versions of dependencies, but also provides the checksums of its dependencies for build system to verify. From this security aspect, maybe we need to commit Cargo.lock along with Cargo.toml? Go team clearly point out this reason in doc https://go.dev/wiki/Modules#should-i-commit-my-gosum-file-as-well-as-my-gomod-file. |
|
Please read the recent blog post "Change in Guidance on Committing Lockfiles", and the up-to-date guidance. |
|
I read through the links provided in the comments, and @weihanglo 's posting was the only one to provide a currently active doc link: https://doc.rust-lang.org/cargo/faq.html#why-have-cargolock-in-version-control |
I'd consider us a binary package, so [we should track our lock file in vcs](rust-lang/cargo#315). Better for auditing shipped dependencies and better for build cache/reproducibility.
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
The text was updated successfully, but these errors were encountered: