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

Add short flag -w for --workspace #11554

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`

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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`
Projects
None yet
Development

No branches or pull requests

4 participants