Repository navigation
A non-member path package's .workspace = true becomes a version dependency with an empty version #714
Description
Observed
A path package that is not a workspace member cannot resolve .workspace = true. A library of build logic that the members' build programs import is such a package; GalTranslPP's gpp.build is one.
# root
[workspace]
members = ["app", "tool"]
[workspace.dependencies]
mcpp.plugins = { path = "…" }
# buildlib/mcpp.toml, reached from app as { path = "../buildlib", host-module = true }
[build-dependencies]
mcpp.plugins = { workspace = true, features = ["rules-qt"], host-module = true }warning: 'mcpp.plugins' is declared as a path dep (by 'app (build-dep)', …) and as a version dep (by 'ws.buildlib@path (build-dep)', ); the root's declaration wins.
The entry is read as a version dependency whose version is empty. It is neither inherited nor refused.
Making the package a member resolves the entry. It also makes mcpp build at the root build the package as a target, and a module-only package whose module imports a host module fails there:
Workspace building member 'buildlib'
mcpp.rules.qt: error: failed to read compiled module: No such file or directory
Consequently the plugin version has to be written twice: once in [workspace.dependencies] and once in the helper.
Request
Either a path package inside the workspace's tree resolves .workspace = true against that workspace, or the entry is refused with a message that names the reason. An empty version should not be accepted silently.
Activity
2026.9.27.1: #704-#716 fixed, feature tools, artifacts edges, payload…
speak-agent commentedon Sep 27, 2026
Fixed in mcpp 2026.9.27.1 (#719, merged as b439fd9), released on GitHub and mirrored to GitCode (xlings-res/mcpp), and published in the xim index (openxlings/xim-pkgindex#894).
Verified after the release with the published binary inside an xlings subos sandbox (
xlings subos use eco-0927 --sandbox --cmd ...), mcpp configured for the CN mirror in a freshMCPP_HOME:lib1 = { workspace = true }inside a workspace that declareslib1: the build is refused naming[dependencies] lib1 = { workspace = true }, but no workspace declares 'lib1'and the fix; 2026.9.26.2 reported an empty SemVer constraint instead.[build] sources = []with a feature supplying the sources infers no library target. PASS.