Add a 'worskpace.default-packages' config to override implied --all?

[SimonSapin]

Since #4335, --all is implied for virtual workspaces. This is not appropriate in some cases (like Servo) for two reasons:

• Two of the "top-level" crates (servo and geckolib) both depend on the same library (style) and each enable a corresponding Cargo feature. These features are mutually exclusive. (Compiling style only works when exactly one of these two "modes" is enabled.)
• --all includes all transitive path dependencies, even though one of those (task_info) is normally only included through a [target.'cfg(target_os = "macos")'.dependencies] section (and doesn’t compile on other platforms).

Both of these are probably unusual, so #4335 is still a good default. But I’d like there to be a way to opt into a different behavior. It could be something like this:

[workspace]
default-packages = ["servo"]

Running e.g. cargo build at the top level without more arguments would behave like cargo build -p servo instead of cargo build --all.

[matklad]

Previously cargo build would just fail in your use case with "this command was invoked with virtual manifest and requires a real one", is that right? So nothing has actually been broken, and this is just a feature request?

Or has #4335 broke some workflow which used to work?

[matklad]

These features are mutually exclusive. (Compiling style only works when exactly one of these two "modes" is enabled.)

This is #4463

[alexcrichton]

Sounds reasonable to me!

[SimonSapin]

@matklad Correct, previously this would fail with that error message. Now it fails later in a build script or in rustc. This is a feature request to enable new workflows.

@alexcrichton Cool, I’ll work on a PR later.

[SimonSapin]

Should the key name be default-members instead?

[matklad]

Should the key name be default-members instead?

FWIW, I don't especially like neither default-members nor default-packages, because the crucial information (default for what?) is missing. However, I don't know a better name, but members are better than packages :(

How should default-members interact with a workspace whose root package is not virtual? Currently, we imply --all for a virtual manifest, but for non-virtual manifest we build only the root package itself. I think default-members should be able to override this behavior.

Let's cc @rust-lang/cargo to brainstorm the better name, and to look at this feature in general :)

[SimonSapin]

My work-in-progress patch does not change the behavior with non-virtual workspaces, but you’re right that using default-members there makes sense too.

[SimonSapin]

Let’s move discussion to #4743.