cargo run in workspace needs to support --package argument

[matklad]

No description provided.

[sanmai-NL]

Would it be most appropriate to make --package a general cargo argument instead of any subcommand's argument?

[alexcrichton]

@sanmai-NL not necessarily, because commands like cargo install or cargo owner don't accept it.

[sunjay]

Would love to see this! Even better would be if I could use the same run syntax as before but cargo would build and run the appropriate executable in my packages.

To explain further, let's say I had this structure:

src/
  bin/
    a.rs
    b.rs
    bb.rs

I used to be able to run:

cargo run --bin a
cargo run --bin b
cargo run --bin bb

With workspaces, I split that into two crates like this:

a/
  src/
    bin/
      a.rs
b/
  src/
    bin/
      b.rs
      bb.rs

It would be really nice if I could still run the same commands as above. The executable names are still the same and unique. They just belong to different crates in the same workspace now.

If the executables across crates aren't unique, then you should definitely make -p required, but otherwise it's way more ergonomic (and easier to remember) to just use the old commands.

It's the difference between cargo run -p b --bin b and cargo run --bin b.

[matklad]

@sunjay that's an interesting idea!

This also reminds me of #2941.

I think that the general problem is that we have boatload of things (packages, targets (which can be bin, lib, example (which now themselves can be bin or lib!)), items withing targets), and all these things use somewhat ad-hoc command-line flags for identification.

@alexcrichton I wonder if perhaps we want some kind of DSL to identify stuff, like various ways of referring to revision in git? The benefits would be

• a universal way to identify anything (mainly for tools): no distinction between bin, lib, etc,

• more convenient command line interface: run foo runs foo if there's only one match.

[alexcrichton]

Yeah seems reasonable to me! I don't quite have an idea of what it would look like, but it'd be neat for tests as well I think

[sunjay]

@alexcrichton now that this is implemented and closed? Should I open a new issue for what I suggested? I would still really like that feature.

[alexcrichton]

@sunjay sure!