Workspace path dependencies and inherited index paths cannot be centralized reliably #224

Summary

The workspace mechanism can enumerate and build members, but two workspace behaviors make it difficult to centralize a real multi-package project configuration at the workspace root:

1. Local path dependencies cannot be declared in [workspace.dependencies] and inherited by members.
2. A root [indices] path is inherited/rebased relative to the member directory instead of the workspace root.

The first behavior may be intentional, but the second produces an incorrect path and appears to contradict the documented configuration inheritance behavior. Together they force every member to repeat path and index configuration.

Environment

• mcpp: 0.0.93
• host: Linux x86_64
• compiler resolved by mcpp: GCC 16.1.0
• repository: a source-only MC++ workspace with many local library members and one CLI member

Reproduction 1: local path dependency through workspace.dependencies

Workspace root mcpp.toml:

[workspace]
members = ["modules/bundler", "mbun"]

[workspace.dependencies]
bundler = { path = "modules/bundler" }

Member mbun/mcpp.toml:

[package]
name = "mbun"
version = "0.1.0"

[dependencies]
bundler = { workspace = true }

Run from the workspace root:

$ mcpp build -p mbun
Workspace building member 'mbun'
Resolving toolchain
Resolved gcc@16.1.0
Updating package index (auto-refresh)
error: dependency 'bundler' has SemVer constraint '' but the index entry isn't cloned locally yet — run `mcpp index update` first

The dependency is a local path dependency, so attempting to resolve it as an index/SemVer dependency is unexpected. The error also does not identify that path dependencies are unsupported in workspace.dependencies.

The documented workspace guide says that [workspace.dependencies] centralizes dependency versions, while path dependencies remain member-local. If that is the intended design, a clear validation error and explicit documentation would help. If path dependencies are intended to be supported, they should resolve relative to the workspace root.

Reproduction 2: root index path rebasing

Workspace root mcpp.toml:

[workspace]
members = ["mbun"]

[indices]
mbun = { path = "mcpp" }

The local index is at:

<workspace-root>/mcpp/index.toml

A member dependency uses a package from that index, for example:

[dependencies.mbun]
openssl = "3.1.5+mbun.1"

Run:

$ mcpp build -p mbun
Workspace building member 'mbun'
Resolving toolchain
Resolved gcc@16.1.0
error: dependency 'mbun.openssl': not found in local index at '<workspace-root>/mbun/mcpp'

The expected lookup path is:

<workspace-root>/mcpp

The same root index declaration is therefore not usable by a member unless the member adds a duplicate declaration with a member-relative path:

[indices]
mbun = { path = "../mcpp" }

Nested members require different duplicated paths such as ../../mcpp.

Expected behavior

For workspace-inherited configuration:

• Relative paths declared in the workspace root should resolve relative to the workspace root.
• A workspace dependency pointing to a local member should either resolve as a path dependency or fail during manifest validation with a precise unsupported-feature error.
• A member should not need to duplicate the same local index declaration with a different relative path.
• Nested member depth should not change the meaning of root configuration.

Possible implementation direction

1. Preserve the workspace root directory in the resolved workspace configuration.

2. Resolve inherited path values, including [indices], against that root rather than the consuming member directory.

3. Support local path entries in [workspace.dependencies] with member usage such as:

   [workspace.dependencies]
   bundler = { path = "modules/bundler" }

   and:

   [dependencies]
   bundler.workspace = true

4. If local path workspace dependencies are intentionally out of scope, reject them before index resolution and document the limitation next to the workspace dependency examples.

5. Add regression tests covering both virtual workspaces and root-package workspaces, including members at different directory depths.

This matters for large MC++ projects because repeated path and index declarations cause configuration drift and prevent a clean root-level workspace manifest.