Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
bromls opened this issue Jan 10, 2023 · 2 comments
Labels
A-lockfile Area: Cargo.lock issues C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-package S-triage Status: This issue is waiting on initial triage.

Comments

@bromls
Copy link

bromls commented Jan 10, 2023

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:

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]
@bromls bromls added the C-bug Category: bug label Jan 10, 2023
@weihanglo
Copy link
Member

This piece of code controls the behavior you described sits here

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.

@weihanglo weihanglo added Command-package A-lockfile Area: Cargo.lock issues C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` and removed C-bug Category: bug labels Jan 12, 2023
@ia0
Copy link

ia0 commented Mar 28, 2023

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

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 epage added the S-triage Status: This issue is waiting on initial triage. label Nov 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lockfile Area: Cargo.lock issues C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-package S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

4 participants