Workspaces inheritance breaks for a workspace located in a sub-directory of another workspace

[jarhodes314]

Problem

If I have two workspaces structured like the following:

.
├── Cargo.lock
├── Cargo.toml  <- root workspace file
├── README.md
├── inner-workspace
│   ├── Cargo.toml <- another workspace defined in a sub-directory
│   └── example-lib
│       ├── Cargo.toml
│       └── src
│           └── lib.rs
└── outer-workspace-crate
    ├── Cargo.toml
    └── src
        └── main.rs

where example-lib uses workspace inheritance to inherit the package version from inner-workspace, e.g. with the Cargo.toml:

[package]
name = "example-lib"
version = { workspace = true }
edition = "2021"

and example-lib is added as a path dependency to outer-workspace-crate, running pretty much any cargo subcommand will fail with:

error: failed to load manifest for workspace member `.../outer-workspace-crate`

Caused by:
  failed to load manifest for dependency `example-lib`

Caused by:
  failed to parse manifest at `.../inner-workspace/example-lib/Cargo.toml`

Caused by:
  error inheriting `version` from workspace root manifest's `workspace.package.version`

Caused by:
  `workspace.package.version` was not defined

This appears to be caused by cargo attempting to inherit the package version from the root Cargo.toml rather than inner-workspace/Cargo.toml. If I add:

[workspace.package]
version = "0.1.0"

to the root Cargo.toml, everything works as expected. Similarly, if I move inner-workspace to not be a sub-directory of the root workspace, the cargo commands work as expected.

Steps

I have created an minimal reproduction here: https://github.com/jarhodes314/cargo-workspace-inheritance-repro, and explained in that README the structure that is required.

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.69.0 (6e9a83356 2023-04-12)
release: 1.69.0
commit-hash: 6e9a83356b70586d4b77613a6b33f9ea067b9cdf
commit-date: 2023-04-12
host: x86_64-unknown-linux-gnu
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 7.86.0-DEV (sys:0.4.59+curl-7.86.0 vendored ssl:OpenSSL/1.1.1q)
os: Ubuntu 22.04 (jammy) [64-bit]

[epage]

From the workspace docs

All path dependencies residing in the workspace directory automatically become members.

So example-lib is automatically becoming part of the outer workspace

[weihanglo]

Sound like you need a nested workspace? See #5042 and this draft.

I am more curious to know why you require a nested workspace instead of just one root workspace. What do you benefit from an additional workspace? Is there any alternative before nested workspace gets implemented? We have been collecting the real world nested workspaces usage. A practical scenario would be very helpful. Thank you!

[jarhodes314]

Sound like you need a nested workspace? See #5042 and this draft.

I am more curious to know why you require a nested workspace instead of just one root workspace. What do you benefit from an additional workspace? Is there any alternative before nested workspace gets implemented? We have been collecting the real world nested workspaces usage. A practical scenario would be very helpful. Thank you!

The other workspace is coming from a git submodule. My particular use case involves both building binaries and depending on libraries from the nested workspace, so this isn't really suitable for e.g. git dependencies.

It's not a huge issue, I can put my workspace in an adjacent directory, or manually exclude the offending packages. I was mostly intrigued as to why this was happening, and I think I've established that now.

[weihanglo]

Thank you so much for the detail!

The other workspace is coming from a git submodule. My particular use case involves both building binaries and depending on libraries from the nested workspace, so this isn't really suitable for e.g. git dependencies.

Git submodules is indeed a scenario that nested workspaces could help. Now we've got another data point from you!

Seems like you agree on this being a nested workspace issue, and I believe the current behavior is intentional (see #12154 (comment)). As such, I am going to close this in favor of #5042. If we miss something, don't hesitate please tell us!