Feature Request: cargo new --in-workspace [directory] [name]

[jamescostian]

The problem

Imagine you're working in a project called foo and it's a workspace. You want to create a new member, bar, as a subdirectory of foo. If you use cargo new bar (or mkdir bar && cd bar && cargo init) you'll get warnings like this:

warning: compiling this new crate may not work due to invalid workspace configuration

current package believes it's in a workspace when it's not:
current:   [new project's Cargo.toml]
workspace: [encompassing workspace's Cargo.toml]

this may be fixable by ensuring that this crate is depended on by the workspace root: 
[encompassing workspace's Cargo.toml]

Ideally, that manual work should be automated (if the user wants it).

There's more manual work if you don't want subdirectories. For example, if foo is in code/foo and you want to make bar in code/bar, then you have to change the Cargo.toml files in both directories after using cargo new

The solution

In the case of creating bar as a subdirectory, you'd cd to the workspace root and use cargo new --in-workspace . bar and foo/Cargo.toml would be updated to include bar in its [workspace] section. In the case of creating bar outside of the root, you'd use cargo new --in-workspace ../foo bar as an example. Similar capabilities should also be given to cargo init for consistency

If the directory passed to --in-workspace is not a workspace, then there would be an error.

I've never contributed to cargo before (and am pretty new to Rust) but I don't think this is too complicated, and if the idea is accepted I'd love to try and implement it. The changes would take place in this file. Add a boolean to NewOptions, change its constructor, update this behavior to change the workspaces section of the root's Cargo.toml (and the child's package.workspace if the child isn't a subdirectory of the root), and it'll be mostly done.

Notes

This is not a breaking change. The new behavior only goes into effect when a new argument (--in-workspace) is specified.

Relevant reading: the original RFC

Alternative ideas:

• cargo new --root [directory] [name]
• cargo new --member [name] - strictly for subdirectories (only addresses foo/bar example; does not address the issue of creating code/bar when your root is code/foo)

[kornelski]

I've ran into "compiling this new crate may not work" error a few times, too.

It's a bit silly that Cargo makes a non-working crate, knows it, even knows how to fix it, but just leaves it broken.

To me it would make most sense if Cargo just automatically added the new crate to the workspace.members in this situation.

[jamescostian]

That sounds pretty reasonable, and the only way I could see that breaking anything is if someone is depending on using cargo new programmatically and from within a crate. But that's quite an edge-case, so it's pretty likely that your suggestion would work perfectly

[matklad]

There's a reverse problem as well, exemplified by this thread:

https://salsa.zulipchat.com/#narrow/stream/145099-general/topic/revamped.20API/near/155324150

If a user creates, via cargo new, a parent/Cargo.toml and a parent/child/Cargo.toml, they naively expect that they've created a workspace, while it's not actually the case. What's bad about this situation is that the user doesn't get any warnings: everything works, it just uses path dependencies instead of workspaces. cargo test works, it just does not test everything.

I think it's clear now that workspaces are the default mode for working on multi-crate projects. I suggest the following change to cargo new / cargo init behavior:

• if the path to the new crate is not a part of the workspace, add an empty [workspace] section to Cargo.toml
• if the path is part of the workspace, adjust the members key (if it exists), or add the new crate as a path-dependency (printing that this was done).

That is, cargo new should always operate with workspaces, by either creating a fresh new one, or adding a member to an existing one.

[czipperz]

What is the progress here? I would really like this feature.

[jamescostian]

I'm no longer using rust, so I'm not interested in contributing to fixing this. But if anyone is willing to take the torch on this, I think it would be beneficial to the rust community (or, at least to the parts of the rust community that like modular code)

[czipperz]

Now that I think about this more, I'm coming to the conclusion that adding a flag to new/init is the wrong approach. This is because the user gets the warning after the action has already completed and these commands cannot be re-ran (they cause an error the second time as it has already been initialized). Maybe we should have a cargo add-to-workspace command? But then it seems like it's not much better than just doing it yourself since it's a pretty easy change.

[kornelski]

There are 3 options here:

1. Add to workspace automatically
2. Don't add to workspace automatically
3. Do nothing, and ask user what to do instead (e.g. by erroring new and telling user to call cargo add-to-workspace if they mean it)

AFAIK 2 creates a create that won't work, so it's broken. Option 3 is asking whether you want a broken crate or a non-broken crate, which is absurd (or a very very edge case at best). So that leaves 1 as the only sensible option?

[czipperz]

But 1 removes backwards compatibility and makes automation hard. I do agree, if we were doing this from the ground up we should do the first.

[kornelski]

Why would any existing users rely on cargo new producing a crate that can't be used?

When do you need to automate creation of unusable crates?

[czipperz]

It's still completely usable. It's just not part of the workspace. Try it in a local repository. It works fine, just there are two Cargo.lock files and two target directories.

[czipperz]

So let's say that cargo new will automatically add the crate to the workspace, which as we all agree on is the most logical path to pursue. Should it automatically create a workspace entry if one doesn't exist? IE it adds the following lines to the Cargo.toml file:

[workspace]
members = ["subcrate"]