Specify "default-run" binary in a workspace project

[andrewdavidmackenzie]

Describe the problem you are trying to solve
I have a workspace project with a Cargo.toml in the root, then various sub-projects in sub-folders, each with their own Cargo.toml files that specify specific packages (libs or binaries).

I often have to execute one of the resulting binaries on test apps during development.

I am pleased to see the addition of the "default-run" key to Cargo.toml in packages section.
In general this will help.
In this project I don't have any sub-project that has multiple binaries built.
I do have multiple binaries built in the overall workspace, one in each of a number of sub-projects.

Describe the solution you'd like
I would like to be able to specify "default-run" in the root workspace Cargo.toml file, so from the project root I can run "cargo run -- " on some test files, without having to specify the binary with --bin <binary_name> each time.

Notes
Not sure under which key would make sense in the workspace toml.
Format something like:
default-run = "sub-folder/binary_name" ?

[ehuss]

If you set default-members in the [workspace] definition to just one package, cargo run should work without specifying the bin. Would that work for you?

[andrewdavidmackenzie]

That looks good @ehuss !! Thanks!

I've wondered in the past what was the purpose of "members" and "default-members".
Is it for this or also for other purposes? Any docs explaining its use?

[ehuss]

default-members helps when you have a "main" crate and a bunch of support crates, and the main one is the primary one you build. You can read more about the motivation in #4507 and the documentation is at https://doc.rust-lang.org/cargo/reference/manifest.html#package-selection.

[andrewdavidmackenzie]

Thanks. That helps. Should have spotted it before.
Although not exactly the same, I think we can close this issue now.
Closing. Reopen if you see any benefit in it.

[andrewdavidmackenzie]

OK, so now I just did find a downside to that approach.

Before, I could execute the binary in any of the sub-projects by using --bin option.
Now, as that is no longer in "default-members" that doesn't work.

Here's a simplified version

before

[workspace]
members = ["flowc", "flowr"]
default-members = ["flowc", "flowr"]

I could execute flowc or flowr using the --bin option, but it is always needed

after

[workspace]
members = ["flowc", "flowr"]
default-members = ["flowc"]

"cargo run" runs "flowc" as discussed - great.
"cargo run --bin flowr" gives an error:
error: no bin target namedflowr`

    Did you mean `flowc`?

`

[ehuss]

Can you try out the latest nightly version? Just a few days ago, we changed this behavior (#7270), which I think should match your expectations.

[andrewdavidmackenzie]

I tried with nightly and seems to be the same behaviour to me:

[workspace]
members = ["flowc", "flowr", "provider", "flowstdlib", "flowrlib", "flowclib", "nodeprovider"]
default-members = ["flowc"]

$ cargo -V cargo 1.39.0-nightly (3f700ec43 2019-08-19)

$ cargo run --bin flowr error: no bin target named flowr`

    Did you mean `flowc`?`

[ehuss]

Oh, I may have misread what you were doing. You should be able to run cargo run --bin flowr from the flowr directory. If you are in another directory, you can run cargo run -p flowr. The new behavior is that inside a subdirectory, it defaults to selecting the current directory's package. default-members will only apply in the root directory.

You can also set up an alias to do whatever you want it to do.

[andrewdavidmackenzie]

aha!
It seems the -p argument is not documented in cargo's own help (or at least not in cargo 1.37.0)
Thanks!

[xixixao]

Also it would be helpful to improve the error message:

error: `cargo run` could not determine which binary to run. Use the `--bin` option to specify a binary, or the `default-run` manifest key.
available binaries: a, b

when run is run from a workspace - otherwise people will have to google and find this issue, like me. Could be:

error: `cargo run` could not determine which binary to run. Use the `-p` option to specify a package, or the `default-members` manifest key.
available binaries: a, b

[jyn514]

If you set default-members in the [workspace] definition to just one package, cargo run should work without specifying the bin. Would that work for you?

Hmm, this works, but it also affects all other commands (e.g. cargo test will only test the one package, instead of all of them). Would it be possible to accept default-run in the top-level virtual workspace? That would avoid changing any of the other behavior beside cargo run.

[mathew-horner]

Hmm, this works, but it also affects all other commands (e.g. cargo test will only test the one package, instead of all of them). Would it be possible to accept default-run in the top-level virtual workspace? That would avoid changing any of the other behavior beside cargo run.

I know it has been a couple years, but I think this ticket should be re-opened on these grounds.

---

To add a real world example:

We have a cargo workspace for one of our backend services. We have a "primary" binary inside a crate (call it A). A contains multiple binaries for various tasks. We have default-run on this crate to run that primary binary.

We also have other supporting crates, one of which is a custom testing framework (call it B). Similar to A, B contains multiple binaries for various tasks and a default-run on the custom test runner binary.

We want to, but are unable to configure the following behavior:

cargo run - Runs the primary binary from crate A.
cargo test - Runs the entire workspace cargo test suite.

[dboeger1]

Funny, I just hit this today and found @mathew-horner commented on the same day. As I understand it, the current recommendation is to use some combination of default-members, -p, and -alias to customize behavior according to a project's needs. I have mixed feelings about this.

On the one hand, I acknowledge that workspaces, packages, and crates are different things, and I could see wanting to avoid an explosion of duplicate, potentially-confusing set options across all of them.

On the other hand, I would argue that this is a usability issue, and if the official stance was not to introduce unnecessary options, I'm not sure default-run and default-members need to exist in the first place. Presumably, they were introduced to improve developer productivity and increase the ubiquity of the standard cargo build/cargo run/cargo test commands without having to figure out a myriad of options every time we open up a new project or clone a repo to start working. In particular, I find it unfortunate that migrating from a single package to a workspace effectively breaks either default-run or cargo test without additional configuration or adjustment of workflows. I'm also not convinced that mirroring one really useful option like default-run is necessarily a slippery slope to worse duplication, although admittedly, I'm a beginner Rustacean with no insight into the behind-the-scenes workings of cargo, so maybe I'm missing something the cargo devs thought of.

It just seems like a completely natural thing to have a default-run in workspaces which doesn't affect other commands like cargo test. That's my 2 cents.