Commit a Cargo.lock file.

[frewsxcv]

No description provided.

[nagisa]

Why?! What purpose does this serve other than eventually resulting in regressions?

[Manishearth]

Fair point.

[frewsxcv]

cargo-fuzz is a binary crate (not a library crate). binary crates should have the lockfile committed, right?

[nagisa]

I don’t see how it being a binary crate warrants a lockfile. Are the version bounds not tight enough in the Cargo.toml? Alternatively, who will take upon the task of updating the lockfile once in a while so the regression like I linked above doesn’t happen eventually?

[frewsxcv]

http://doc.crates.io/guide.html#cargotoml-vs-cargolock

[Manishearth]

Binaries usually check in lockfiles.

However, cargo install doesn't respect these so it doesn't matter. If you don't install via cargo install, checking in a lockfile is a good idea.

[frewsxcv]

However, cargo install doesn't respect these so it doesn't matter.

Ah, didn't know this. In that case, sure, we should remove it.

[frewsxcv]

I don’t see how it being a binary crate warrants a lockfile.

One example scenario: If I download a version a binary built via cargo, I want to have the exact dependencies I used to compile that binary committed to version control so I can easily go back and reproduce the issue. If I don't commit the lockfile, when I go back, I'm installing potentially different dependencies which could make it harder to reproduce the issue.

[nagisa]

This point does not apply as much as you'd want it to. Libraries can depend on unstable rustc details that aren't quite behind the façade (via symbols for example) and your stuff may still break/not repro anymore; similar to the non-bug I linked above.

…

On Mar 1, 2017 12:28 AM, "Corey Farwell" ***@***.***> wrote: I don’t see how it being a binary crate warrants a lockfile. One example scenario: If I download a version a binary built via cargo, I want to have the *exact* dependencies I used to compile that binary committed to version control so I can easily go back and reproduce the issue. If I don't commit the lockfile, when I go back, I'm installing potentially different dependencies which could make it harder to reproduce the issue. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#43 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AApc0kT89swvVZkHhq6fST0Oqqjat_RSks5rhJ99gaJpZM4MN9S7> .

[frewsxcv]

I'm talking about stable Rust. If I ship a new release of a binary that just includes a bump of an upstream dependency (which is very common), it's good to have the git history reflect that bump, otherwise, it would look like nothing changed.