Option to highlight one or several packages in cargo tree output

[bazzilic]

Problem

Sometimes, when trying to figure out an issue with dependencies, it's useful to take a look at cargo tree. However, in a big project it takes time to find the package of interest among lots and lots of dependencies. Highlighting a package with color would be very useful in a scenario like this.

Proposed Solution

I'd like to propose optional colorized highlighting of packages based on substring search. E.g., cargo tree --highlight serde.

Additionally, it may take several substrings and highlight them in different colors, e.g.
cargo tree --highlight serde,cpufeatures or
cargo tree --highlight serde --highlight cpufeatures

Argument of --highlight does not have to be an exact match but rather do a substring match, so instead of serde I can use rde and match serde and rdesktop.

Output should resemble what you can currently achieve using egrep and a little regex hack:
cargo tree | egrep 'serde|$'

Although this function to some extent is possible to achieve using external tools such as egrep, it feels like this should be part of cargo tree itself.

Notes

No response

[weihanglo]

Although this function to some extent is possible to achieve using external tools such as egrep, it feels like this should be part of cargo tree itself.

Out of curiosity. Why do you think this feature should be built-in, given existing tools perform pretty decent today?

As I can see, the workflow of this kind of search has a lot of human interactions. That means most users wanting this feature are probably in an interactive session, which is highly possible to have a better tool like egrep or ripgrep. That said, Cargo can still have this feature built-in. We just need compelling points to convince people.

[bazzilic]

Why do you think this feature should be built-in, given existing tools perform pretty decent today?

In my opinion, without it cargo tree is useless on any decent sized project: it spits out several screens of text, where it would take a lot of time to find the package you are looking for, and often easy to miss an important entry. So for cargo tree to be useful on its own, on some basic level, highlighting must be built-in, IMO.

But it should be a simple feature with simple syntax; for complex cases where you need more than simple highlights, users can pipe into all kinds of great tools such as grep, awk, sed, and utilize the full power of CLI text processing :)

[weihanglo]

Thanks for the reply. I'd like to learn more about this part — “cargo tree is useless on any decent sized project”. How large is it making cargo tree useless? Is it possible for you to share a project suffering from this? Also, I'd like to know your workflow in detail that is painful without this feature. Maybe the issue is not about highlight but some other aspects of cargo tree.

Let me share mine first. If I want to find a dependency, usually use cargo tree -p <pkg> to narrow down the scope, or cargo tree -i <pkg> to invert the tree. Those flags is largely helpful when a dependency tree is quite huge. If I am going to search the tree back-and-forth, I would just cargo tree | less or view the output inside vim/emacs/editors.

---

Okay. Let's see pros and cons of having this feature or not.

With existing external tools,

• 👍🏾 No need to learn a new Cargo flag
• 👍🏾 No need to implement a new feature
• 👍🏾 Pick tools you like and make your own workflow
• 😭 You need those tools installed in your system.

OTOH, with this proposal implemented,

• 👍🏾 Built-in basic highlighting support
• 😭 Add complexity to Cargo codebase
• 😭 Need to learn and remember there is a new flag
• 😭 Less powerful than existing well-known tools

(I made an assumption that people generally know some tools)

I always ask myself a question when I come up an idea of a new feature: Does the lack of this feature block somebody's workflow and there is no alternative? I tend to be sold easier when the answer is “yes”.

[bazzilic]

Useless was a bad choice of word, I meant to say hard to use on its own. I guess cargo tree -i <pkg> can help with this, I revisited this flag and realized I misunderstood what it does on the first attempt.

Maybe you are right that this flag is unnecessary and same results could be achieved by a combination of other flags and tools. But IMO, cargo tree is an exploratory tool for visual inspection and a) colors are a good fit for this kind of tools; and b) not being a blocker is not always enough: cargo tree itself does not unblock any workflows, everything it does could be done via other means, including manually.

[weihanglo]

As we somehow agree on pros and cons on each solution, I am going to close this as not-planned in order to move things forward. In terms of being an exploratory tool, #11213 may be a good alternative and git has been using it for a while. I do appreciate you putting time in the discussion of improving the user experience of Cargo. If anyone has a different idea, please let us me. Thank you!