Automatically inherit workspace fields when running cargo new

[epage]

Problem

When I create a new workspace, cargo new populates some fields but leaves me to fill in the rest. If I run it within a workspace with workspace.package fields set, I most likely intend to inherit those in this new crate as well.

Proposed Solution

When cargo new is run, search up for a possible workspace. If one is found, check which workspace.package fields are set and then in the new package, set those fields to <field>.workspace = true.

Notes

See #10859

I don't think this is blocked on #6378 because cargo new in a workspace that uses globs in members will automatically pick up the new crate and doesn't need #6378 to take advantage of this.

[Googleton]

Hi, just to make sure I understand this issue before possibly tackling it:

I have a top level workspace 'my-workspace' which has this in its Cargo.toml:

(...)
[workspace.package]
description = "hello world"

I then run cargo new my-package (in the same directory as my-workspace's Cargo.toml).
The expected content of the newly created Cargo.toml:

[package]
name = "my-package"
version = "0.1.0"
edition = "2021"
description.workspace = true

Of course, assuming we have the workspace inheritence feature enabled.

[epage]

The expected content of the newly created Cargo.toml:

Yes

We have to make sure fields like edition are overwritten rather than duplicated (a risk if simple string manipulation is used).

I have a slight preference for the order of the fields in workspace.package to be mirrored in package.

Of course, assuming we have the workspace inheritence feature enabled.

I'd just wait until #10859 is merged. We are halfway done with the FCP which is blocking the stablization

[Googleton]

Thank you for the information.

I will be trying to do it while waiting for the merge, as a way to dig into the cargo codebase. I will keep your concerns/preferences in mind, it should make for a fun learning experience!

[epage]

Tips

• You most likely want find_workspace_root to find the workspace root.
  • Loading the workspace to find the root might fail because of Feature Request: cargo new --in-workspace [directory] [name] #6378
  • The fix for Feature Request: cargo new --in-workspace [directory] [name] #6378 will need to use find_workspace_root anyways and no point loading the root twice
• Loading the workspace in toml_edit will let you observe the ordering.
  • There is parse_document which will give you a consistent error experience

[Googleton]

To load the workspace, I was looking here: https://github.com/rust-lang/cargo/blob/master/src/cargo/ops/cargo_new.rs#L844-L851

It seemed to me like this would be the correct place: If the result is not an Err, we have a proper workspace and can go from there to get InheritedFields and then write them into the newly created Cargo.toml

Again, thank you for the advice :)

[SummerGram]

Why did it open again?

[Rustin170506]

@rustbot claim

[ehuss]

Just to be clear, will this only be done if the workspace.members has a glob that will pick up the new package?

[epage]

For now, yes. #6378 is for adding it to the workspace. glob support I think is common enough to not block one of these on the other.