Allow specifying `--package` before the subcommand

[tgross35]

Problem

Sometimes I am developing a specific crate within a workspace, and development workflow consists of a handful of subcommands for that same crate:

cargo test --package some-package
cargo clippy --package some-package --all-targets
cargo add --package some-package serde

This is mildly cumbersome in terminal because in order to change the subcommand, the cursor needs to be moved around --package some-package (or -p).

Proposed Solution

It would be nice if --package could be passed to the root cargo command, and then be used by any subcommands:

cargo --package some-package test
cargo --package some-package clippy --all-targets
cargo --package some-package add serde

# specifying multiple times is a failure
cargo --package some-package add --package some-package serde

This makes it a bit easier to work with since there is a "base command" for whatever crate is being worked on, and then the trailing subcommand is easier to change. The alignment also makes things somewhat nicer to read in scripts.

Notes

This would make --package somewhat analogous to the unstable -C, which is a good thing in my opinion (workflows with other tooling that supports -C is often similar with a base command / subcommand split).

[weihanglo]

Cargo indeed has a concept of “common options” that can be used before subcommands, though are technical issues:

• Not all commands have/need --package. For example cargo update has migrated away and favors positional argument.
• Some allows only one (cargo-rustc) while others accept multiple (cargo-build).
• cargo clippy is an external command. It is a bit cumbersome to capture --package first then pass to clippy.

To me, I would weigh on the code complexity versus the flexibility we gain (it is indeed more convenient I agree).

[epage]

To add to what @weihanglo said, we have global arguments that don't need to and I feel it was a mistake to make them global.

Another angle for this is a CLI parser could auto-correct this by acting as if any unknown flags before the subcommand were really given after the subcommand. However, CLI parsing is context dependent and you can't definitively identify what are subcommands vs flag values vs positionals. See also clap-rs/clap#3056

Whether making them global or making subcommand flags to be present before the subcommand, solving this does not seem worth it. I would propose we close this.