Heuristics to include Cargo.lock or not in a package are suboptimal

[sdroege]

Problem

Context is: https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/499

The setup here is a workspace with multiple cdylib/staticlib/rlib crates. When publishing them, the ones with an example or binary will have their Cargo.lock included in the package, the others not:

    /// Returns if package should include `Cargo.lock`.
    pub fn include_lockfile(&self) -> bool {
        self.targets().iter().any(|t| t.is_example() || t.is_bin())
    }

This seems a bit arbitrary in this situation. Some of the crates have examples, some not 🤷

In practice this causes problems if people get the crates from crates.io and try to build the cdylib/staticlib, e.g. via cargo-c, and use --frozen to ensure that the same Cargo.lock is used as during publishing.

Steps

1. Create a cdylib crate
2. cargo publish --dry-run and check whether the Cargo.lock is included in target/package` (it is not)
3. Add an example to the crate
4. cargo publish --dry-run and check whether the Cargo.lock is included in target/package` (it is included now)

Possible Solution(s)

I would suggest to update the heuristic above to either include cdylib/staticlib crates, and/or to provide some kind of configuration in Cargo.toml whether the Cargo.lock should be included or not.

If something is decided, I'd be happy to implement this.

Notes

No response

Version

cargo 1.76.0 (c84b36747 2024-01-18)
release: 1.76.0
commit-hash: c84b367471a2db61d2c2c6aab605b14130b8a31b
commit-date: 2024-01-18
host: x86_64-unknown-linux-gnu
libgit2: 1.7.1 (sys:0.18.1 vendored)
libcurl: 8.5.0-DEV (sys:0.4.70+curl-8.5.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Fedora 39.0.0 [64-bit]

[epage]

While the sympton is different, there is some overlap in the solution space with #13306 (see also https://blog.rust-lang.org/inside-rust/2024/02/13/this-development-cycle-in-cargo-1-77.html#rfc-3537-make-cargo-respect-minimum-supported-rust-version-msrv-when-selecting-dependencies).

[sdroege]

Somewhat related (one could also use the Cargo.lock to ensure no dependencies that require a newer toolchain are used), but in this case the reason for using --frozen etc is for reproducible builds, specifically usage of always the same versions of dependencies unless explicitly updated.

[sdroege]

@epage So as you said the focus should be on this issue (in #14769), how should this move forward? For this specific issue it seems like simply having

[package]
publish-lockfile = true

would solve the issue. If not specified, it would use the current heuristic, otherwise whatever value was provided.

If the naming and behaviour makes sense to you, I would be happy to implement that.

[epage]

I've proposed we discuss this in the next Cargo team meeting. I would go with unconditionally including Cargo.lock. In my opinion, its not worth a configuration value and a heuristic has been insufficient so far. Having it in there for libraries also has other benefits for a cargo publish verify step and for cargo-semver-checks.

[sdroege]

Sounds good to me

[epage]

@sdroege we discussed this in today's team meeting and have Accepted this issue, opening the way for moving forward with it.

The original motivation for the heuristic is recorded in #5093 (comment). This was intended purely for cargo install and things have evolved a lot since then. It makes sense at this point for us to always include the lockfile. There are several benefits and very few downsides (slightly larger but compresses well, theoretically we include a file that isn't always needed).

[sdroege]

Great, thanks! I'll take a look at providing a PR then.

EDIT: Mostly a matter of updating all the tests that assume no Cargo.lock is there.

[sdroege]

See #14815