Workspace path dependencies and inherited index paths cannot be centralized reliably

[Sunrisepeak]

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.

[Sunrisepeak]

Additional workspace issue: mcpp run cannot select a binary member from a virtual workspace

This is a second reproducible workspace limitation related to member-scoped operations.

Environment

• mcpp: 0.0.93
• repository: virtual workspace root with member mbun
• member manifest: mbun/mcpp.toml
• binary target:

[targets.mbun]
kind = "bin"
main = "src/main.cpp"

Reproduction

From the virtual workspace root:

mcpp build
mcpp run mbun

The build succeeds, but run fails while resolving the current root package:

Finished release [optimized] in 0.03s
error: no binary target 'mbun' found

mcpp run --help currently documents only:

USAGE:
    mcpp run [OPTIONS]
    mcpp run <target>

There is no -p / --package option for run, and unlike workspace build / test, run does not fan out or select a member package.

Current workaround

Running from the member directory works:

(cd mbun && mcpp run -- --version)

This successfully builds and runs:

Running `target/x86_64-linux-gnu/.../mbun`
1.3.14

Expected behavior

One of these interfaces should work from a virtual workspace root:

mcpp run -p mbun -- --version
# or
mcpp run --package mbun -- --version
# or
mcpp run mbun -- --version

The last form is currently ambiguous because mbun can be interpreted as either a member/package name or a binary target name. An explicit package option would be preferable.

Suggested implementation

Reuse the package selection logic already used by build and test:

1. Add --package / -p to the run subcommand.
2. Resolve the selected workspace member before calling build_run_target.
3. Build and run the selected member's binary target.
4. If no package is selected at a virtual workspace root, report the available members or require an explicit package instead of searching only the root package.

This should be handled separately from the path dependency and index inheritance issue documented above, but both affect normal member-scoped commands in a workspace.

[Sunrisepeak]

✅ 已在 mcpp 0.0.97 修复(PR #236,c044f8e,簇 G)。

• 复现 1([workspace.dependencies] 的 path 依赖):merge_workspace_deps 现传播 path(及 git 字段),并按 workspace 根解析相对路径,成员经 .workspace = true 可正常继承本地 path 依赖(顺带修了 [workspace.dependencies] 扁平键 x = { path = ... } 被误解析为 x.path 的 bug)。
• 复现 2(root [indices] 相对路径重基):继承的 [indices] 相对 path 现按 workspace 根解析(而非消费成员目录),根部声明一次全员可用,成员不再需重复写 ../ 相对路径。

附带落地了 R6:[indices] default = { path = "..." }(亦接受 "")可重定向默认命名空间到本地 checkout(url 形式显式报错),使 index 仓能用 mcpp test --workspace 声明式验证模块包;以及 mcpp run -p <member>。

验证:e2e 120_ws_root_indices.sh / 121_default_ns_redirect.sh / 122_run_member.sh。