Tracking issue for --unit-graph · Issue #8002 · rust-lang/cargo (original) (raw)

Skip to content

Navigation Menu

• • GitHub Copilot Write better code with AI
  • GitHub Advanced Security Find and fix vulnerabilities
  • Actions Automate any workflow
  • Codespaces Instant dev environments
  • Issues Plan and track work
  • Code Review Manage code changes
  • Discussions Collaborate outside of code
  • Code Search Find more, search less
• Explore
  • Learning Pathways
  • Events & Webinars
  • Ebooks & Whitepapers
  • Customer Stories
  • Partners
  • Executive Insights
• • GitHub Sponsors Fund open source developers
  • The ReadME Project GitHub community articles
• • Enterprise platform AI-powered developer platform
• Pricing

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sign up

Description

Implementation: #7977
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#unit-graph

Summary
The --unit-graph flag emits a JSON structure showing Cargo's internal unit graph.

Unresolved issues

• Is there a better way to expose this information? I think in many cases, to make this useful, you have to also run cargo metadata (to get package names, for example). It seems a little silly to have to run two commands. Adding this to cargo metadata I think will be hard from a UX standpoint. It would require a superset of all flags of all commands (for example, cargo check --profile=test fundamentally changes things, so it would need to reproduce that flag). Every time I look at that, it seems really messy. There's also some flags like --target that don't interact with cargo metadata very well.
  • The primary motivator is to get access to feature relationships. But maybe there is a better way to deal with that?
• Which parts of the output should be stabilized? This structure is very low-level, and thus inherently at high risk of changing in the future and being unstable. I think at a minimum we should document that it is not guaranteed to be backwards compatible. Should we filter some fields on stable?
• Can't differentiate a normal check and a check for a test. The serialize implementation for CompileMode does not output the different kinds. Not sure how this should be displayed.