packaging: omit generated Cargo.lock if binaries and examples are package-excluded

[bromls]

Problem

When running cargo package --no-verify --no-metadata -p <my_package>

Expected behavior: a generated Cargo.lock is produced for the package if and only if the package contains one or more examples or binaries.

Observed behavior: If the package has examples/**, but has marked the path as excluded (https://doc.rust-lang.org/cargo/reference/manifest.html#the-exclude-and-include-fields), a Cargo.lock is still generated despite the examples being excluded from the <package>.crate file.

Steps

No response

Possible Solution(s)

No response

Notes

This is admittedly an edge condition, but we have a CI flow where it is important to be able to avoid the Cargo.lock generation step. We are packaging multiple dependent crates from a workspace simultaneously for submission to an alternative registry with no API (direct registry index manipulation), so the failed registry lookups that occur during Cargo.lock generation break our ability to package the crates simultaneously.

We would not want to .gitignore the examples, as we want them there for developers of the crates. However, any other exclusion mechanism (if there are reasons not to overload https://doc.rust-lang.org/cargo/reference/manifest.html#the-exclude-and-include-fields) would be appropriate.

The workaround we currently use is to avoid examples inside publishing crates, instead putting them in separate crate(s) in the same workspace.

This is related to:

• Uncommitted Cargo.lock files prevent reproducing .crate files from source  #9242
• Presence of binaries or examples causes "dev-dependencies" metadata to be required for cargo package #7487

Version

cargo 1.65.0 (4bc8f24d3 2022-10-20)
release: 1.65.0
commit-hash: 4bc8f24d3e899462e43621aab981f6383a370365
commit-date: 2022-10-20
host: aarch64-apple-darwin
libgit2: 1.5.0 (sys:0.15.0 vendored)
libcurl: 7.85.0 (sys:0.4.55+curl-7.83.1 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 13.1.0 [64-bit]

[weihanglo]

This piece of code controls the behavior you described sits here

cargo/src/cargo/sources/path.rs

Lines 153 to 167 in abc6abe

	let filter = |path: &Path, is_dir: bool| {
	let relative_path = match path.strip_prefix(root) {
	Ok(p) => p,
	Err(_) => return false,
	};
	let rel = relative_path.as_os_str();
	if rel == "Cargo.lock" {
	return pkg.include_lockfile();
	} else if rel == "Cargo.toml" {
	return true;
	}
	ignore_should_package(relative_path, is_dir)
	};

The fix might be simple. Call the clouse ignore_should_package(…) earlier, and inside fn include_lockfile(…) try to determine if target.src_path() is ignored. Then determine the reult from these two booleans.

To me, it seems quite hacky but actually reasonable, since the package doesn't include any example ro binary anymore. However, I've seen several counter proposals advocating that every package even a library only package should commit its Cargo.lock to VCS, specifically, #8728. I don't have an obvious answer at the time being.

[ia0]

I'm either misunderstanding something, or there's a misunderstanding. My understanding is that:

• cargo package should not package the Cargo.lock for libraries (even if they have examples as long as those examples are not included in the package) from this issue packaging: omit generated Cargo.lock if binaries and examples are package-excluded #11557
• Cargo.lock files should always be tracked in version control (like git) even for libraries because of reproducibility from Check Cargo.lock in version control for libraries #8728 linked above

For me, those 2 statements are not incompatible and that's what I expect from the following situation:

• I have a library crate with examples.
• I just want to publish the library (i.e. the src directory only, not the examples directory).
• I don't want to publish the Cargo.lock.
• I want to track the Cargo.lock for my continuous integration to be reproducible.
• I'll manually and regularly update my Cargo.lock to test early for breakages in compatible updates. But this is done as an isolated step to not break reproducibility.

[epage]

In #14815, the Cargo team has decided to always include Cargo.lock. As there is no more heuristic, I don't see a reason to keep this open.