Add new packages to [workspace.members] automatically

[calavera]

What does this PR try to resolve?

If a new package is created in a workspace, this change adds the package's path to the workspace's members list automatically.

It doesn't add the package to the list if the path is in the workspace's exclude list, or if the members list doesn't exist already. I noticed that a cargo_new test broke if I create the members list when it doesn't exist. This is because the workspace's manifest can be used for package templating. I think it's better to not break that use case.

Fixes #6378

How should we test and review this PR?

I've included tests in the cargo_new suite.

[ehuss]

r? epage

[calavera]

@epage it looks like there are some formatting incompatibilities when running the tests with Windows MSVC stable. Is there a way to insert the data correctly regardless of the version? See this example:

   4    4 |     "crates/bar",
   5      -     "crates/foo",
        5 +     'crates/foo',
   6    6 | ]

https://github.com/rust-lang/cargo/actions/runs/6460323327/job/17537796417?pr=12779#step:10:3698

Is there a reason why toml_edit uses single quotes on Windows? I cannot see any way to change that behavior.

[calavera]

I've also noticed that this comparison fails on Windows, I'm guessing because of encoding issues. When I try to debug it, the values seem to be displayed correctly, but the comparison fails:

let pat = member.as_str().unwrap();
if pat == relpath {
    return Ok(());
}

println!("{} - {} EQUAL {}", pat, relpath, pat == relpath);

crates/foo - crates/foo EQUAL false

Is there a way to do this consistently across platforms?

[epage]

Could you show the debug representation for each?

[calavera]

Could you show the debug representation for each?

oh, thanks for the hint! it looks like the relative path returned from pathdiff has two slashes on Windows:

"crates/foo" - "crates//foo" EQUAL false

I've changed the implementation to compare Path elements, and fix the path separator differences when the path is serialized in the Cargo.toml file.

[calavera]

I've added a test for cargo init too.

@epage let me know what you think about these changes.

[epage]

At this point, it comes down to what we want out policy to be for formatting.

[calavera]

At this point, it comes down to what we want out policy to be for formatting.

@joshtriplett's suggestion makes sense to me: https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Automatic.20edits.20to.20.60Cargo.2Ctoml.60/near/395834270

What this means in this case:

1. If there is already a members list, the format of the list is preserved.
2. If there is not a members list in the manfest already, the format doesn't break anything. The list is always added as the last element to the workspace elements list. The format for this last element follows the same format as the previous last element.

[epage]

Let's go ahead and remove the auto-formatting but keep the relevant tests. If nothing else, this is an improvement over what we already have and changing it isn't a breaking change.

[calavera]

@epage I've cleaned up the auto-formatting logic. The only formatting left is something that would really bother me as a user if we didn't do, which is adding a new line between the members element and any inline table below.

This are two relevant tests for that formatting:

• https://github.com/rust-lang/cargo/pull/12779/files#diff-b98fac4d8d67ba38266192cb38c293ff58175d48322f9b83d42747430cb03f55
• https://github.com/rust-lang/cargo/pull/12779/files#diff-5d552a1c107329b928f2a2b93946966a5f8cce2e9192c8294c5d5e46fcf667d3

Let me know what you think.

[epage]

Everything at this point is minor. Feel free to clean up the commits.

[calavera]

@epage I've reworked the commits to make the changes more isolated. I put dependency changes in separated commits, and the feature implementation itself in one commit. I don't think the changes in cargo_new are big enough to grant a more fine grained separation because everything is encapsulated in a new method.

Let me know what you think.

[epage]

Thanks!

@bors r+

[bors]

📌 Commit 1a8bfdf has been approved by epage

It is now in the queue for this repository.

[bors]

⌛ Testing commit 1a8bfdf with merge 04621e2...

[bors]

☀️ Test successful - checks-actions
Approved by: epage
Pushing 04621e2 to master...