feat(tree): Color the output

[epage]

What does this PR try to resolve?

This is an experiment to find ways to make cargo tree output easier to grok. I find too many details are hard to spot because everything looks the same.

The goal is to make it easier to scan the output for relevant details. So far, this approach seems the most viable. Knowing what type of edges led to where you are provides useful context for scrolling through large lists of dependencies.

How should we test and review this PR?

I had considered styling normal dependency edges but there isn't a header to clarify what they mean, so I decided to match the package name as that is the header. So this didn't buy as much as I had hoped, especially since dimmed lines aren't obvious with my terminal. Maybe if we used different unicode graph characters.

Instead of coloring the "this is elided" (*), I had considered using a unicode character that looks like its pointing from that item up. I only found one that looked close to that but the origin for the arrow was bottom aligned, rather than center aligned and it looked off.

Alternatives considered

• Once an edge is marked with dev or build dependencies, all future edges inherit it
  • While this makes it clear what section you are in, so does the outer most line
• Feature edges are the color of the edges that led to them
  • Unsure of value either way
  • This might get weird with --invert
• Style local nodes different than non-local
  • With the format string being user customizable, I'm concerned with styling over or within user styling
• Rainbow packages: For every package in the same namespace (.split_once("::").0) or prefix (.split_once(['-','_']).0), assign a color (maybe only for the top N packages to reduce duplicate colors)
  • Would help a lot with gix-* and similar other cases
  • If we cap the number of participating packages, would need care to work with --depth

(of course,. these could be mixed)

Additional information

[rustbot]

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

[weihanglo]

• Once an edge is marked with dev or build dependencies, all future edges inherit it
  • While this makes it clear what section you are in, so does the outer most line
• Feature edges are the color of the edges that led to them
  • Unsure of value either way
  • This might get weird with --invert

Also need to think about artifact dependencies, which make the color choice more chaos 😬. Maybe, the color should follow on the package being inspected via -p, not its direct dependant.

As for features, what about give (feature-name) a color, instead of coloring the tree.

And yeah, --invert is tricky, We can also color the tree invert, but then I am not sure which color the --invert <root> node shall be, if there are multiple dependant.

[weihanglo]

Looks good to me, though I'm not sure if everyone agrees. Should we start with nightly only first so we can iterate on the design?
So after some time, we'll have multiple nightly toolchains to compare different colorschemes all at once.

[epage]

Also need to think about artifact dependencies, which make the color choice more chaos 😬. Maybe, the color should follow on the package being inspected via -p, not its direct dependant.

I assume those are regular edges. However, it might be interesting to draw those as dashed or something.

As for features, what about give (feature-name) a color, instead of coloring the tree.

That is part of the user-templated string and the user could be adding their own coloring which could make things messy. We could possibly detect user colors and make our own conditioned on that. I decided to just punt on any styling of user-formatted text for now.

Looks good to me, though I'm not sure if everyone agrees. Should we start with nightly only first so we can iterate on the design?

Nightly only is a bit annoying with some of the compile-time constants being done.