dependable tree now resolves a nested, independent workspace's crates against their own root: a fuzz/ tree with its own [workspace.package] version = "0.0.0" gives its crate that version, instead of leaving it blank because the outer root had no authority to supply one. That came out of #110.
The version is now right. What it came from is invisible:
$ dependable tree root
a v1.0.0 (workspace)
a-fuzz v0.0.0 (workspace)
Both render identically. a is a member of the workspace being scanned; a-fuzz belongs to a separate workspace that Cargo would not include in this graph at all, and its 0.0.0 was read from a different root's [workspace.package] table. Nothing in the output says so. A reader comparing the two versions has no way to tell that they were resolved under different authorities — which matters more now than it did when the nested crate simply had no version, because a blank was at least conspicuous.
Why it was left out of #110
Saying it needs somewhere to say it. Node carries name, version, and kind, and none of those can express "governed by a different workspace root":
NodeKind classifies what a package is (Workspace, Registry, Git, Path), not which workspace claims it. Adding a variant would change what existing consumers match on, and a nested crate genuinely is a workspace crate — just not this workspace's.- A new field on
Node is a public-model change across three crates: Node lives in dependable-core, the TUI renders it, and tree --format json serializes it. That schema is a compatibility surface.
#120 declined a change of the same class for the same reason — distinguishing a version a manifest declared from one a lockfile resolved — so this is the second question waiting on the same decision. If provenance is ever added to Node, both are answered at once, and deciding them together is probably cheaper than either alone.
Worth deciding at the same time
- Whether provenance belongs on
Node at all, or whether WorkspaceGraph should carry it beside the graph — it already carries GraphSource there rather than on each node, which is the existing precedent for "how this was determined" living outside the node model.
- Whether the
tree renderer should mark it at all, or whether this is only a --format json concern for tooling. A tree that annotates every node loses the scannability that makes it readable.
dependable treenow resolves a nested, independent workspace's crates against their own root: afuzz/tree with its own[workspace.package] version = "0.0.0"gives its crate that version, instead of leaving it blank because the outer root had no authority to supply one. That came out of #110.The version is now right. What it came from is invisible:
Both render identically.
ais a member of the workspace being scanned;a-fuzzbelongs to a separate workspace that Cargo would not include in this graph at all, and its0.0.0was read from a different root's[workspace.package]table. Nothing in the output says so. A reader comparing the two versions has no way to tell that they were resolved under different authorities — which matters more now than it did when the nested crate simply had no version, because a blank was at least conspicuous.Why it was left out of #110
Saying it needs somewhere to say it.
Nodecarriesname,version, andkind, and none of those can express "governed by a different workspace root":NodeKindclassifies what a package is (Workspace,Registry,Git,Path), not which workspace claims it. Adding a variant would change what existing consumers match on, and a nested crate genuinely is a workspace crate — just not this workspace's.Nodeis a public-model change across three crates:Nodelives independable-core, the TUI renders it, andtree --format jsonserializes it. That schema is a compatibility surface.#120 declined a change of the same class for the same reason — distinguishing a version a manifest declared from one a lockfile resolved — so this is the second question waiting on the same decision. If provenance is ever added to
Node, both are answered at once, and deciding them together is probably cheaper than either alone.Worth deciding at the same time
Nodeat all, or whetherWorkspaceGraphshould carry it beside the graph — it already carriesGraphSourcethere rather than on each node, which is the existing precedent for "how this was determined" living outside the node model.treerenderer should mark it at all, or whether this is only a--format jsonconcern for tooling. A tree that annotates every node loses the scannability that makes it readable.