CARGO-TREE(1)

📦 version 1.78.0, in ubuntu jammy, ubuntu noble

💅 CARGO-TREE(1) — like, the whole manual, bestie 🎀

okay so this is the manual page for cargo-tree, which lives in the General Commands Manual section of your man pages. it's giving "here's how you look at your dependency graph and feel something." let's get into it ✨

🌸 NAME

cargo-tree — displays a tree visualization of a dependency graph. that's it. that's the whole job. and she does it gorgeously. 🌈

✨ SYNOPSIS

cargo tree [options]

literally just that. <purple>options</purple> are where all the fun lives, and there are a LOT of them (iykyk). 💅

🦋 DESCRIPTION

so bestie, this command shows you a tree of dependencies right there in your terminal. picture a simple project that depends on the rand package — here's what that looks like:

myproject v0.1.0 (/myproject)
`-- rand v0.7.3
    |-- getrandom v0.1.14
    |   |-- cfg-if v0.1.10
    |   `-- libc v0.2.68
    |-- libc v0.2.68 (*)
    |-- rand_chacha v0.2.2
    |   |-- ppv-lite86 v0.2.6
    |   `-- rand_core v0.5.1
    |       `-- getrandom v0.1.14 (*)
    `-- rand_core v0.5.1 (*)
[build-dependencies]
`-- cc v1.0.50

see those little (*) marks? 👀 packages marked with (*) have been "de-duplicated". translation: the dependencies for that package have already been shown somewhere else in the graph, so she's not about to repeat herself. if you WANT the duplicates repeated (no judgement, some people are completionists), use the --no-dedupe option. 🫶

✨ pro tip that is actually just a fact: the -e flag lets you pick which dependency kinds get displayed. and the "features" kind? that one changes the whole output to show you the features enabled by each dependency. iconic behaviour. for example, cargo tree -e features:

myproject v0.1.0 (/myproject)
`-- log feature "serde"
    `-- log v0.4.8
        |-- serde v1.0.106
        `-- cfg-if feature "default"
            `-- cfg-if v1.0.10

okay so let's read this tree together: myproject depends on log with the serde feature. and log, in turn, depends on cfg-if with "default" features. cute, right? 🎀

when you're using -e features it can be super helpful to also use the -i flag, so you can see how the features flow into a package. there are examples below with more detail — go look, I'll wait. 💜

👑 Feature Unification

this command shows you a graph that's much closer to a feature-unified graph — like, the one Cargo is actually going to build — rather than whatever you happened to list in Cargo.toml. for instance: say you specify the same dependency in both [dependencies] and [dev-dependencies], but with different features turned on. this command may merge all the features and show a (*) on one of the dependencies to indicate the duplicate. periodt. 💅

so as a result — and this is the useful part — if you want a mostly equivalent overview of what cargo build does, then cargo tree -e normal,build is pretty close. and if you want a mostly equivalent overview of what cargo test does, then plain old cargo tree is pretty close. 🌸

⚠️ however — and I need you to hear me on this — it doesn't guarantee the exact equivalence to what Cargo is going to build, since a compilation is complex and depends on lots of different factors. do not come for her when the tree and the build disagree. she warned you fr fr. 😭

wanna learn more about feature unification? there's a whole dedicated section for it at:

https://doc.rust-lang.org/cargo/reference/features.html#feature-unification

go read it, it's giving educational. 🦋

✨ OPTIONS ✨

🌳 Tree Options

-i spec, --invert spec — bestie, this one flips the whole thing 💅 it shows the reverse dependencies for the package you name — so instead of "what does this need", you get "who needs this". It literally inverts the tree and displays the packages that depend on the given package.

Heads up though: in a workspace, by default it only shows the package's reverse dependencies inside the tree of the workspace member in the current directory. Want more? The --workspace flag extends it so you get the package's reverse dependencies across the entire workspace. And the -p flag can display the package's reverse dependencies only with the subtree of the package given to -p. 🌸

--prune spec — snips the given package right out of the dependency tree display. Gone. Not invited. 🙈
--depth depth — how deep do we go, bestie? Maximum display depth of the dependency tree. A depth of 1 displays the direct dependencies, for example.
--no-dedupe — ok so normally, when a package has already shown its dependencies, further occurrences won't re-display them and instead get a little (*) to say "yeah we already did this one". This flag says no ma'am, repeat those duplicates anyway. 💀
-d, --duplicates — shows only dependencies that come in multiple versions (and yes, it implies --invert). When you use it with the -p flag, it only shows duplicates within the subtree of the given package.

And here's the tea ☕ — avoiding building that same package multiple times can be genuinely beneficial for build times and executable sizes. This flag helps you identify the offending packages. Then you can go investigate whether the package that depends on the duplicate with the older version can be updated to the newer version so that only one instance is built. slay, efficiency 🫶

-e kinds, --edges kinds — which dependency kinds do we display? Takes a comma separated list of values:
- all — Show all edge kinds.
- normal — Show normal dependencies.
- build — Show build dependencies.
- dev — Show development dependencies.
- features — Show features enabled by each dependency. If this is the only kind given, then it will automatically include the other dependency kinds.
- no-normal — Do not include normal dependencies.
- no-build — Do not include build dependencies.
- no-dev — Do not include development dependencies.
- no-proc-macro — Do not include procedural macro dependencies.

⚠️ The normal, build, dev, and all dependency kinds cannot be mixed with no-normal, no-build, or no-dev dependency kinds. Pick a lane, bestie.

The default is normal,build,dev.

--target triple — filters dependencies matching the given target triple (https://doc.rust-lang.org/cargo/appendix/glossary.html#target). The default is the host platform. Use the value all to include all targets. 🌈

🎀 Tree Formatting Options

--charset charset — picks the character set for the tree. Valid values are utf8 or ascii. When unspecified, cargo will auto-select a value. It just knows. ✨
-f format, --format format — sets the format string for each package. The default is {p}.

This is an arbitrary string which will be used to display each package. These strings get swapped out for the corresponding value:

{p} — The package name.
{l} — The package license.
{r} — The package repository URL.
{f} — Comma-separated list of package features that are enabled.
{lib} — The name, as used in a use statement, of the package's library.

--prefix prefix — sets how each line is displayed. The prefix value can be one of:
- indent (default) — Shows each line indented as a tree.
- depth — Show as a list, with the numeric depth printed before each entry.
- none — Show as a flat list.

📦 Package Selection

By default, when no package selection options are given, the packages selected depend on the selected manifest file (based on the current working directory if --manifest-path is not given). If the manifest is the root of a workspace then the workspace's default members are selected, otherwise only the package defined by the manifest will be selected.

The default members of a workspace can be set explicitly with the workspace.default-members key in the root manifest. If this is not set, a virtual workspace will include all workspace members (equivalent to passing --workspace), and a non-virtual workspace will include only the root crate itself. that's just how it is, no cap 💅

-p *spec*…, --package *spec*… — display only the specified packages. See cargo-pkgid(1) for the SPEC format. This flag may be specified multiple times and supports common Unix glob patterns like *, ? and []. However — and this is the important bit — to avoid your shell accidentally expanding glob patterns before Cargo handles them, you must use single quotes or double quotes around each pattern. 👑
--workspace — display all members in the workspace. all of them. the whole squad. 🫶
--exclude *SPEC*… — exclude the specified packages. Must be used in conjunction with the --workspace flag. This flag may be specified multiple times and supports common Unix glob patterns like *, ? and []. However, to avoid your shell accidentally expanding glob patterns before Cargo handles them, you must use single quotes or double quotes around each pattern. same energy as above fr fr

📜 Manifest Options

--manifest-path path — path to the Cargo.toml file. By default, Cargo searches for the Cargo.toml file in the current directory or any parent directory. it goes looking, bestie 🔍
--frozen, --locked — either of these flags requires that the Cargo.lock file is up-to-date. If the lock file is missing, or it needs to be updated, Cargo will exit with an error. The --frozen flag also prevents Cargo from attempting to access the network to determine if it is out-of-date.

These may be used in environments where you want to assert that the Cargo.lock file is up-to-date (such as a CI build) or want to avoid network access. 🧚

--offline — prevents Cargo from accessing the network for any reason. Without this flag, Cargo will stop with an error if it needs to access the network and the network is not available. With this flag, Cargo will attempt to proceed without the network if possible.

😭 Beware that this may result in different dependency resolution than online mode. Cargo will restrict itself to crates that are downloaded locally, even if there might be a newer version as indicated in the local copy of the index. See the cargo-fetch(1) command to download dependencies before going offline.

May also be specified with the net.offline config value (https://doc.rust-lang.org/cargo/reference/config.html).

🌟 Feature Selection

The feature flags let you control which features are enabled. When no feature options are given, the default feature is activated for every selected package. cute and simple 💖

See the features documentation (https://doc.rust-lang.org/cargo/reference/features.html#command-line-feature-options) for more details.

-F features, --features features — space or comma separated list of features to activate. Features of workspace members may be enabled with package-name/feature-name syntax. This flag may be specified multiple times, which enables all specified features. stacking them like accessories ✨
--all-features — activate all available features of all selected packages. go big or go home 🔥
--no-default-features — do not activate the default feature of the selected packages. respectfully declining 🎀

💅 Display Options

-v, --verbose — use verbose output. May be specified twice for "very verbose" output which includes extra output such as dependency warnings and build script output. May also be specified with the term.verbose config value (https://doc.rust-lang.org/cargo/reference/config.html). spill the tea, twice ☕
-q, --quiet — do not print cargo log messages. May also be specified with the term.quiet config value (https://doc.rust-lang.org/cargo/reference/config.html). shhh 🤫
--color when — control when colored output is used. Valid values:
- auto (default): Automatically detect if color support is available on the terminal.
- always: Always display colors.
- never: Never display colors.

May also be specified with the term.color config value (https://doc.rust-lang.org/cargo/reference/config.html). 🌈

👑 Common Options

+toolchain — if Cargo has been installed with rustup, and the first argument to cargo begins with +, it will be interpreted as a rustup toolchain name (such as +stable or +nightly). See the rustup documentation (https://rust-lang.github.io/rustup/overrides.html) for more information about how toolchain overrides work.
--config KEY=VALUE or PATH — overrides a Cargo configuration value. The argument should be in TOML syntax of KEY=VALUE, or provided as a path to an extra configuration file. This flag may be specified multiple times. See the command-line overrides section (https://doc.rust-lang.org/cargo/reference/config.html#command-line-overrides) for more information.
-C PATH — changes the current working directory before executing any specified operations. This affects things like where cargo looks by default for the project manifest (Cargo.toml), as well as the directories searched for discovering .cargo/config.toml, for example. This option must appear before the command name, for example cargo -C path/to/my-project build. order matters bestie 🫶

This option is only available on the nightly channel (https://doc.rust-lang.org/book/appendix-07-nightly-rust.html) and requires the -Z unstable-options flag to enable (see #10098 https://github.com/rust-lang/cargo/issues/10098).

-h, --help — prints help information. when in doubt, ask 📖
-Z flag — unstable (nightly-only) flags to Cargo. Run cargo -Z help for details.

🌍 ENVIRONMENT

See the reference (https://doc.rust-lang.org/cargo/reference/environment-variables.html) for details on environment variables that Cargo reads. 👀

🚦 EXIT STATUS

0: Cargo succeeded. we ate. 💖
101: Cargo failed to complete. it's giving tragedy 😭

✨ EXAMPLES ✨

okay bestie this is the part where it all clicks, fr fr. five little recipes, each one a whole vibe 💅

Wanna see the tree for whatever package is chillin' in your current directory? Say less:

cargo tree

Wanna know every single package that depends on the syn package? Invert that graph, queen:

cargo tree -i syn

Wanna peek at which features are enabled on each package? We're showing off today:

cargo tree --format "{p} {f}"

Wanna catch all the packages that get built multiple times? 👀 This can happen when multiple semver-incompatible versions show up in the tree (like 1.0.0 and 2.0.0) — so they just both gotta be there, no cap.

cargo tree -d

Wanna explain why features are enabled for the syn package? This is the main character move:

cargo tree -e features -i syn

The -e features flag is what shows the features, and the -i flag is what inverts the graph so it displays the packages that depend on syn instead of the ones syn depends on. Here's an example of what that would display:

syn v1.0.17
|-- syn feature "clone-impls"
|   `-- syn feature "default"
|       `-- rustversion v1.0.2
|           `-- rustversion feature "default"
|               `-- myproject v0.1.0 (/myproject)
|                   `-- myproject feature "default" (command-line)
|-- syn feature "default" (*)
|-- syn feature "derive"
|   `-- syn feature "default" (*)
|-- syn feature "full"
|   `-- rustversion v1.0.2 (*)
|-- syn feature "parsing"
|   `-- syn feature "default" (*)
|-- syn feature "printing"
|   `-- syn feature "default" (*)
|-- syn feature "proc-macro"
|   `-- syn feature "default" (*)
`-- syn feature "quote"
    |-- syn feature "printing" (*)
    `-- syn feature "proc-macro" (*)

To read this graph, you can follow the chain for each feature from the root to see why it is included. For example, the “full” feature is added by the rustversion crate, which is included from myproject (with the default features), and myproject is the package selected on the command-line. All of the other syn features are added by the “default” feature (and btw “quote” is added by “printing” and “proc-macro”, both of which are default features). It's giving detective work 🔍✨

If you're having difficulty cross-referencing the de-duplicated (*) entries, try with the --no-dedupe flag to get the full output. That's your rescue, bestie 🫶

🌸 SEE ALSO 🌸

cargo(1)
cargo-metadata(1)

okay that's the whole page, and the lil footer at the very bottom just says CARGO-TREE(1) — that's the source/version tag and the date slot, and honestly? she ate. 💅 no notes. go forth and tree your dependencies, bestie, you got this 👑💖

📦 where this page comes from

ubuntu jammy: cargo-1.78 1.78.0+dfsg1ubuntu1~bpo0-0ubuntu0.22.04.1 · Apache-2.0 WITH LLVM exception
ubuntu noble: cargo-1.78 1.78.0+dfsg1ubuntu1-0ubuntu0.24.04.2 · MIT OR Apache-2.0
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-10-13: a language model's rewrite of the original, under its terms