Skip to content

Add short flag -w for --workspace #11554

New issue

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

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

Already on GitHub? # to your account

Open
SUPERCILEX opened this issue Jan 8, 2023 · 3 comments
Open

Add short flag -w for --workspace #11554

SUPERCILEX opened this issue Jan 8, 2023 · 3 comments
Labels
A-cli Area: Command-line interface, option parsing, etc. 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.

Comments

@SUPERCILEX
Copy link

SUPERCILEX commented Jan 8, 2023

See discussion here: #11549

Key points:

Thus, we're blocked on #9339

@SUPERCILEX SUPERCILEX added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label Jan 8, 2023
@weihanglo weihanglo added the A-cli Area: Command-line interface, option parsing, etc. label Jan 8, 2023
@epage
Copy link
Contributor

epage commented Jan 10, 2023

We talked specifically about consistency with cargo update -w in the cargo team meeting. We felt that improving consistency is important which precludes any other command having a -w that isn't a short for --workspace.

We did not decide how to resolve the inconsistency on the existing -w flag, whether we feel that -w was a mistake that slipped in (and we would want to deprecate) or is something we want to push for in the rest of cargo. That was a wider conversation than we were prepared for and had time for.

@epage
Copy link
Contributor

epage commented Jan 10, 2023

To help move the conversation forward, I personally feel the remaining points are

  • Is the intent of the flag clear enough (mostly summarizing Add short flag for workspace #11549)
    • -w for --workspace would be consistent with npm
    • Some might assume --watch from Add cargo watch #9339
    • From GNU coding standards, the only intuitive (to me) meaning associated with -w is --width which shouldn't be too ambiguous to read as that would take a numeric value
    • Personally, for some reason I also see -w without a value as --write and I didn't even remember that I had used -w in a tool of mine for --write-changes (just now thought to check and I wrote that flag years ago and never used it)
  • Would the flag used frequently enough interactively, where abbreviations help?
    • A rule of thumb I've seen is that short flags shouldn't be used in automation to make the intent clear, that they should only be used for faster human interactions
    • For me, when using cargo check and cargo clippy, if I'm checking the workspace, I want to check everything and I also pass in --all-targets. At that point, --workspace (or the older --all) being shortened doesn't matter all that much. Instead I use make or could use an alias
      • I could see cargo test -w being shorter than cargo test --workspace
      • But for me, a single workflow wouldn't be sufficient justification (hearing how other people interact with cargo would help)

@est31
Copy link
Member

est31 commented Jun 22, 2024

I feel the --workspace flag is way too long to type it out on a regular basis and I've never started to use it. I use --all instead, for example when I want to ensure that I'm not regressing the build of one of the crates in the workspace before making a PR (default-members defaults to all workspace members but it could in theory have been set to a subset). I don't really agree that --all is confusing, but I'm still okay with the removal as long as there is some short alternative to it. Being forced onto --workspace feels like a regression to me.

If -w is not good (say you want to use it for cargo watch), what about --ws?

I feel the same about foo.workspace = true by the way. foo = "ws" as alias for foo.workspace = true would be really wonderful. If you have a bunch of crates like foo.workspace = true then it's hard to scan the dependencies (and hard to add new dependencies because you have to type these long words). ws is not a valid semver version, and if you want to specify features you can still do foo = { workspace = true, feature = ["a"]}, like how you do foo = { version = "1.0", feature = ["a"]} today.

@epage epage added the S-triage Status: This issue is waiting on initial triage. label Nov 20, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-cli Area: Command-line interface, option parsing, etc. 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.
Projects
None yet
Development

No branches or pull requests

4 participants