cargo init is not working great when creating a new workspace with multiple members

[BartMassey]

Problem

Got a spurious warning when creating a workspace component with cargo init or cargo new. Expected it to go without issue. See below.

Steps

1. Created a new workspace with a top-level toml

[workspace]
members = [ "feature-lib", "feature-bin" ]

2. Then made subdirectories for feature-lib and feature-bin.

3. Then went to feature-lib and said cargo init --lib.

Got this error message:

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

failed to load manifest for workspace member `/home/bart/prj/rust/feature-bugs/feature-bin`

Caused by:
  failed to read `/home/bart/prj/rust/feature-bugs/feature-bin/Cargo.toml`

Caused by:
  No such file or directory (os error 2)
     Created library package

The feature-lib toml was created correctly, so the only real issue is the misleading message. When proceeding to feature-bin and running cargo init --bin everything worked normally.

Starting without any new directories and running cargo new --lib feature-lib produced the same error.

Possible Solution(s)

Very low priority to fix, but would be nice to suppress the unavoidable warning message in these cases. Somebody has to be created first. 🙂 . I think it would be sufficient to ignore missing or empty workspace component directories. I'm not sure why this warning exists at all, honestly: what kinds of mistakes does it protect against?

Notes

No response

Version

cargo 1.64.0 (387270bc7 2022-09-16)
release: 1.64.0
commit-hash: 387270bc7f446d17869c7f208207c73231d6a252
commit-date: 2022-09-16
host: x86_64-unknown-linux-gnu
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.83.1-DEV (sys:0.4.55+curl-7.83.1 vendored ssl:OpenSSL/1.1.1q)
os: Debian n/a [64-bit]

[epage]

While in this specific case, the intention was to make the config valid soon with cargo new / cargo init, there can be other cases where the use of the workspace or the state of the workspace isn't clear and this message can help.

Personally, I would

• Suggest members = "crates/*" which will make it less likely to have issues
  • I wonder if we should pull in at least parts of https://matklad.github.io/2021/08/22/large-rust-workspaces.html into the workspace documentation
• Feature Request: cargo new --in-workspace [directory] [name] #6378 which will add crates to the members, avoiding the "which should I edit first" situation in this issue

[BartMassey]

Thanks! Suggest closing this in favor of #6378. The documentation change would be helpful for sure, though.

[BartMassey]

By the way @epage that response time was truly awesome. Thanks much.

[epage]

Wasn't looking at which issue we are on. Considering keeping this open for the documentation side of things.

[rimutaka]

If the suggested options make sense, I'd like to give this a try (@epage):

1. mention the error in cargo-new and cargo-init
2. explain how the workspaces can be organised using https://matklad.github.io/2021/08/22/large-rust-workspaces.html in a separate page under Workspaces
3. both
4. something else? :)

[epage]

I don't think this error is worth mentioning in the docs. It is reporting things how they are.

What we should be doing is adding a section at the bottom of the workspaces page that talks about common practices / recommendations.

We talked some about how to handle recommendations in this zulip thread for #12323.

Related examples

• https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#multiple-version-requirements
• https://doc.rust-lang.org/cargo/reference/resolver.html?highlight=recommend#recommendations
• https://doc.rust-lang.org/cargo/reference/registry-authentication.html?highlight=recommend#recommended-configuration
• https://doc.rust-lang.org/cargo/reference/build-script-examples.html
• https://doc.rust-lang.org/cargo/reference/features-examples.html

[torhovland]

@epage You mean like this?

Recommended structure

Here is a good way to organize workspaces that scales well.

In the root Cargo.toml file, set up a flat directory of workspace members:

[workspace]
members = ["crates/*"]
resolver = "2"

Keep this as a virtual manifest. It might be tempting to put the main crate into the root, but that pollutes the root with src/, requires passing --workspace to every Cargo command, and adds an exception to an otherwise consistent structure.

Next, set up subfolders where the name of each directory is equal to the name of the crate. For example, a crate named hir_def would be defined in crates/hir_def/Cargo.toml like this:

[package]
name = "hir_def"
version = "0.0.0"
edition = "2018"

For really large workspaces, you may want to consider a more hierarchical structure. But a flat structure should serve you well for a long time.

[BartMassey]

This sounds great. In fact, it sounds so great that I feel like maybe cargo new --workspace and cargo new --workspace should set up this default skeleton (with no crates)?