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

--locked-for-binaries flag (same as --locked but only if the crate is / has a binary) #12091

Closed
BKDaugherty opened this issue May 5, 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` S-needs-team-input Status: Needs input from team on whether/how to proceed.

Comments

@BKDaugherty
Copy link

Problem

I have a monorepo that has many crates in it. For every crate, I'd like to ensure that, if it has a binary, the Cargo.lock file is up to date.

In order to do that, I want to run cargo check --locked on all of the binaries that I have, and if it fails I want to fail CI.

Given that the recommendation is that binaries check in their Cargo.lock files and libraries don't, it'd be awesome if there was a cargo command that I could run that would add --locked only if cargo is working on a binary.

I couldn't find an easy way to figure out whether or not a crate had a binary. At the moment, my solution has been...

 $ cargo metadata --format-version 1 --no-deps | jq '.["packages"] | .[] | .targets | .[] | .kind' -c | grep bin && cargo check --bins --locked
 $ cargo check --all-targets

But this means I'm running cargo check twice for each binary I have.

Proposed Solution

Provide a flag --locked-for-binaries where cargo check (and other commands) errors if cargo needs something not in the lock file for binaries, but doesn't error if the Cargo.lock file doesn't exist for libraries.

Notes

No response

@BKDaugherty BKDaugherty added C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage. labels May 5, 2023
@weihanglo
Copy link
Member

weihanglo commented May 13, 2023

Thanks for the idea! It's hard to say whether a specialized flag is good or not. I can see the convenience the flag bringing. Once Cargo stabilizes a flag it will stay forever. We tend to think more before adding flags, especially if there are some (not elegant but working) workarounds.

Besides, the dont-commit-lockfile-for-libraries recommendation is in an interesting situation. Here is a recent discussion around it. I would say, if the official guideline gonna change, this flag might become even less useful. That's why we need to be a bit more conservative toward this proposal.

@weihanglo weihanglo added A-lockfile Area: Cargo.lock issues S-needs-team-input Status: Needs input from team on whether/how to proceed. and removed S-triage Status: This issue is waiting on initial triage. labels May 13, 2023
@BKDaugherty
Copy link
Author

Hey! Just wanted to say I appreciated your diplomatic and welcoming answer @weihanglo! Given #8728, and the fact that my team is now checking in all of the Lockfiles for our libraries too, I'm going to close this.

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` S-needs-team-input Status: Needs input from team on whether/how to proceed.
Projects
None yet
Development

No branches or pull requests

2 participants