Packages for binary crates should include Cargo.lock

[mbrubeck]

Cargo.lock is always excluded from packages generated by cargo package. This means that it can't be used by cargo install when installing from crates.io. Should this be changed for crates that contain binaries, in order to make cargo install more reproducible for these binaries?

[mbrubeck]

Originally reported by @jaxx in https://users.rust-lang.org/t/cargo-install-and-lock-file/4203

[alexcrichton]

Hm yes this seems reasonable to me

[SimonSapin]

for crates that contain binaries

Alternatively include the lock file for all crates, but ignore it when using a dependency.

[alexcrichton]

The relevant line is here and it's there for two reasons:

1. We don't want to consider the Cargo.lock file in terms of "freshness" (e.g. seeing if a package has changed).
2. Historically no one would read it, so we didn't include it. This is of course no longer valid with cargo install being a thing now.

So should just involve fixing it and then ensuring we don't accidentally consider changes to Cargo.lock to rebuild a crate.

[kbknapp]

Just ran into an issue with this in BurntSushi/ripgrep#439

[carols10cents]

Ok so this is currently biting me. I'm trying to publish crates.io on crates.io, to get docs.rs on crates.io's code to help people working on crates.io (bear with me).

Crates.io is an application, really, so its Cargo.lock should be used. In its current state, there's some newer published version of a dependency (not sure which yet) that causes the build to fail. Since cargo package ignores Cargo.lock, cargo build works for me but cargo package fails.

For crates that include both a library and a binary, (ex: bindgen, cargo itself), if we include the Cargo.lock but ignore it sometimes, then there's the possibility that when you build the crate as a binary (and the Cargo.lock is used), the build will succeed, but if you try to use it as a dependency, the build will fail, even though the Cargo.lock is present. I'm concerned that this is surprising behavior but I don't know how to fix it :-/

The comments in BurntSushi/ripgrep#439 are interesting because someone was getting a compiler error and burntsushi wasn't even able to reproduce, because he had a Cargo.lock locally that worked.

My brain is exploding... how does this even work today with just library crates?? When you're working on a library, you have a Cargo.lock locally that gets used for building and tests forever, even though it's gitignored and not published..... I guess this is what CI is for??? Have people run into tests that fail on travis but not locally and the solution to reproduce locally is to delete your local Cargo.lock??

For crates that are both binaries and libraries, should there be a way to request a build as a binary crate using Cargo.lock as well as request a build as a library crate that ignores Cargo.lock?? Without doing cargo package??

It was surprising to me that I could get everything working locally then go to publish and the package verification fails... :(

[steveklabnik]

My brain is exploding... how does this even work today with just library crates?? When you're working on a library, you have a Cargo.lock locally that gets used for building and tests forever, even though it's gitignored and not published..... I guess this is what CI is for??? Have people run into tests that fail on travis but not locally and the solution to reproduce locally is to delete your local Cargo.lock??

FWIW, this is how it works in Ruby as well, and is not generally seen as a major problem.

And yeah, I'd expect CI to catch this kind of thing.

[carols10cents]

And yeah, I'd expect CI to catch this kind of thing.

Except CI can't catch this for crates that are also binaries and check in their Cargo.toml...

[carols10cents]

wait i see that i was talking about libraries there, geez, gotta read my own comments