Skip to content

feat(tree): show artifact dependency details#17075

Open
npmccallum wants to merge 2 commits into
rust-lang:masterfrom
npmccallum:issue-14804-bindeps-tree
Open

feat(tree): show artifact dependency details#17075
npmccallum wants to merge 2 commits into
rust-lang:masterfrom
npmccallum:issue-14804-bindeps-tree

Conversation

@npmccallum

Copy link
Copy Markdown
Contributor

Carry artifact dependency metadata on cargo tree edges and annotate artifact edges with the requested artifact kinds, lib flag, and target when present.

This makes artifact dependencies visible without changing dependency resolution or node identity. Feature-edge output keeps the annotation on the package node so cargo tree -e features still exposes the artifact request.

Closes #14804.

@rustbot rustbot added A-documenting-cargo-itself Area: Cargo's documentation Command-tree S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 4, 2026
@rustbot

rustbot commented Jun 4, 2026

Copy link
Copy Markdown
Collaborator

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: @ehuss, @epage, @weihanglo
  • @ehuss, @epage, @weihanglo expanded to ehuss, epage, weihanglo
  • Random selection from ehuss, epage, weihanglo

}
}

#[derive(Debug, Copy, Hash, Eq, Clone, PartialEq)]

@epage epage Jun 4, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tip: splitting changes like this into their own commit make it easier / faster for maintainers to review, see https://epage.github.io/dev/pr-style/#c-atomic

View changes since the review

.with_status(0)
.run();

p.cargo("tree -Z bindeps -e features")

@epage epage Jun 4, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We ask for new test cases to be added in their own commit first, with tests passing in that commit, see https://epage.github.io/dev/pr-style/#c-test

View changes since the review

Comment thread src/cargo/ops/tree/mod.rs
ws: &Workspace<'_>,
graph: &'a Graph<'_>,
node_index: NodeId,
incoming_edge: Option<&Edge>,

@epage epage Jun 4, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we are relying on the incoming edge. Are there times where we have different edges but the same node? For example, what happens if a package has a regular dep and an artifact dep on a package?

#16192 also deals with edges and may have other relevant concerns.

View changes since the review

r#"...
foo v0.1.0 ([ROOT]/foo)
└── bar v0.1.0 ([ROOT]/foo/bar)
└── bar v0.1.0 ([ROOT]/foo/bar) (artifact: bin, target=[ALT_TARGET])

@epage epage Jun 4, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR is marked as closing the issue but part of the issue is how to visually represent the graph.

View changes since the review

Add cargo tree coverage for artifact dependencies before changing their
visual output. The baseline keeps the current behavior: artifact
dependencies are displayed in their dependency section without
artifact-specific annotation.
Carry artifact dependency metadata on cargo tree edges and annotate
artifact edges with the requested artifact kinds, lib flag, and target
when present.

This keeps the metadata tied to the incoming edge, so a package reached
by both a normal dependency and an artifact dependency only shows the
artifact annotation on the artifact edge.

Refs rust-lang#14804.
@npmccallum npmccallum force-pushed the issue-14804-bindeps-tree branch from 2eb63a0 to 83d0988 Compare June 4, 2026 17:23
@npmccallum

Copy link
Copy Markdown
Contributor Author

I traced the design history through #10593, #14804, #14658, RFC 3028,
and RFC 3176. I did not find an accepted RFC-level output format for
cargo tree.

The concrete proposal in #10593 / #14804 was to annotate artifact
dependencies with the artifact kind, for example (bin), (staticlib),
or (cdylib), optionally including the target in that annotation if we
choose to show it. The prior draft PR #14658 followed that textual suffix
direction.

This PR takes that minimal textual approach, but spells the annotation
out as (artifact: ..., target=...) so the meaning is self-describing.
It keeps artifact dependencies in their existing normal/build/dev
sections and attaches the annotation to the incoming edge, not globally
to the package node. That is why a normal edge and an artifact edge to
the same package render differently.

I did not implement dashed-line rendering in this PR. Line style could
communicate that an edge is a non-linking artifact edge, but it cannot
disambiguate multiple artifact requests to the same package, such as
different artifact kinds, binary selectors, or targets. The target case
is not hypothetical; #17067 allows separate artifact dependency aliases
for the same package with different requested targets. The textual
annotation carries that edge-local detail, and the graph representation
keeps the metadata on the edge so dashed-line rendering remains possible
as a future UI refinement.

If dashed-line rendering would be valuable, I am happy to implement that
as a follow-up once there is agreement on how it should interact with the
textual artifact details.

I also changed this from Closes #14804 to Refs #14804 because the
larger visual design remains open, especially whether cargo tree
should eventually use a distinct line style and how far we want to go
for lib = true rendering.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-documenting-cargo-itself Area: Cargo's documentation Command-tree S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Display artifact dependency information in cargo tree

4 participants