Setting default-member on a workspace makes cargo test only test one project

[gilescope]

Problem

Rust strives itself to not have footguns and make development a pleasure. Unfortunately the current setup of using default-member to set the default cargo run binary is deeply flawed and dangerous: Most of the workspace's tests are no longer run. No warnings are given that you're just running one projects tests rather than the expected full workspace.

Steps

Set default-member = "..." on a workspace Cargo.toml

Possible Solution(s)

It would be better to remove default-member if we're not going to run all the tests as it's such a footgun. (Or add a big warning? - ideally after the test output as there can be a lot of output)

Notes

This has been discussed before ( #7290 ), but I'm opening this as a bug because this is a big footgun. Nobody expects cargo test at the root level of a workspace to just run one project's tests. It can go un-noticed for quite a time if on the CI you just see that all the tests are green. Rust prides itself on being as safe a language as it can be, but in this particular instance we're not living up to our values. (I'm happy to code up any agreed upon solution, but what we have now isn't a great situation.)

Version

No response

[gilescope]

Maybe this should be titled "How to compromise your whole CI setup with this one easy step"?

[epage]

This isn't unique to explicitly setting default-members because a root package in a workspace is automatically a default member if no others are set.

In all of my CI jobs, regardless of whether there is a workspace or not, or a root package or not, I run cargo commands with --workspace.

In theory, the output should make it clear that we are doing what "you" requested (whether you intended it or not). The problem is the output is noisy (including #2832, #4324) so that obscures this.

Considering changing this would be at odds with root packages, we shouldn't change root package behavior, there are strong compatibility requirements around this (mixing in CLI and workspaces which aren't subject to Editions at this time), and part of the problem is the output which we have issues for, I lean towards closing this. If there is anything more to be done, it is likely to reconsider the state of default-run.

If there is a reason for us to reconsider this, let us know!

[gilescope]

So in general when we work with workspaces (isn’t everything in a workspace these days?) we should always specify ‘—workspace’ to be safe?

…

On Fri, 3 May 2024 at 16:25, Ed Page ***@***.***> wrote: This isn't unique to explicitly setting default-members because a root package in a workspace is automatically a default member if no others are set. In all of my CI jobs, regardless of whether there is a workspace or not, or a root package or not, I run cargo commands with --workspace. In theory, the output should make it clear that we are doing what "you" requested (whether you intended it or not). The problem is the output is noisy (including #2832 <#2832>, #4324 <#4324>) so that obscures this. Considering changing this would be at odds with root packages, we shouldn't change root package behavior, there are strong compatibility requirements around this (mixing in CLI and workspaces which aren't subject to Editions at this time), and part of the problem is the output which we have issues for, I lean towards closing this. If there is anything more to be done, it is likely to reconsider the state of default-run. If there is a reason for us to reconsider this, let us know! — Reply to this email directly, view it on GitHub <#13855 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGEJCA6EJYYRW3B2D64R53ZAOT6NAVCNFSM6AAAAABHFBH4HWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJTGIZTSNRSGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>