'cargo tree -i <package>' is empty for windows-only dependency

[RalfJung]

Problem

I am trying to figure out what imports winapi 0.2.8 in https://github.com/iron/iron.

Steps

git clone https://github.com/iron/iron
cd iron
cargo tree -i winapi@0.2.8

Strangely, the result is empty, even though this package definitely appears in the lockfile. I tried adding --workspace --all-features -e all, no luck. Maybe there are more flags I need to pass to say --all-and-i-really-mean-all-of-them? Or is it because the package is a windows-only dependency? I don't have a windows machine though and would like to figure out where these dependencies are coming from...

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.64.0 (387270bc7 2022-09-16)
release: 1.64.0
commit-hash: 387270bc7f446d17869c7f208207c73231d6a252
commit-date: 2022-09-16
host: x86_64-unknown-linux-gnu
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.83.1-DEV (sys:0.4.55+curl-7.83.1 vendored ssl:OpenSSL/1.1.1q)
os: Debian n/a (bookworm) [64-bit]

[weihanglo]

cargo tree is aware of feature unification. I guess we need to pass --target all to include all targets.

[RalfJung]

Thanks, that does it!

So I missed one more all-flag.^^ Is --workspace --all-features -e all --target all enough to really get all all all all dependencies or are there more such flags? ;)

[RalfJung]

The output, however, looks strange...

$ cargo tree -i winapi@0.2.8 --workspace --all-features -e all --target all
winapi v0.2.8 (/home/r/src/rust/tmp/winapi-rs)
└── winapi feature "default" (command-line)
    ├── advapi32-sys v0.2.0 (/home/r/src/rust/tmp/winapi-rs/lib/advapi32)
    │   └── advapi32-sys feature "default"
    │       [dev-dependencies]
    │       └── winapi v0.2.8 (/home/r/src/rust/tmp/winapi-rs) (*)

So winapi depends on itself? I was hoping to figure out where the winapi dependency comes from and I know it goes via hyper, tokio, mio -- but those don't show up in the tree at all.

[weihanglo]

If you're looking for dependencies of iron. Here is the tree I got from iron/iron@cde77e5:

Expand the result of cargo tree -i winapi@0.2.8 --target all under iron/iron

winapi v0.2.8
├── kernel32-sys v0.2.2
│   ├── mio v0.6.23
│   │   ├── tokio v0.1.22
│   │   │   └── hyper v0.12.36
│   │   │       ├── iron v0.6.0 (/Users/whlo/wd/qd/iron/iron)
│   │   │       │   ├── iron-exmaples v0.1.0 (/Users/whlo/wd/qd/iron/examples)
│   │   │       │   ├── mount v0.4.0 (/Users/whlo/wd/qd/iron/mount)
│   │   │       │   ├── persistent v0.4.0 (/Users/whlo/wd/qd/iron/persistent)
│   │   │       │   └── router v0.6.0 (/Users/whlo/wd/qd/iron/router)
│   │   │       └── iron-exmaples v0.1.0 (/Users/whlo/wd/qd/iron/examples)
│   │   ├── tokio-reactor v0.1.12
│   │   │   ├── hyper v0.12.36 (*)
│   │   │   ├── tokio v0.1.22 (*)
│   │   │   └── tokio-tcp v0.1.4
│   │   │       └── hyper v0.12.36 (*)
│   │   └── tokio-tcp v0.1.4 (*)
│   └── miow v0.2.2
│       └── mio v0.6.23 (*)
├── mio v0.6.23 (*)
├── miow v0.2.2 (*)
└── ws2_32-sys v0.2.1
    └── miow v0.2.2 (*)

Seems like it is from hyper, no?

[RalfJung]

Ah I guess the -e all was asking for too much "all".^^ Now I see the same output. I am confused by why it shows hyper and mio as leaves of the tree (basically all the lines below iron-exmaples) but that seems like a problem with the -i flag and not with target/feature selection. All paths from workspace crates to winapi go through hyper indeed.

Maybe in case cargo tree prints nothing, it could print a helpful message suggesting to pass --all-features or --target all or -e ... to enable dependencies that require specific features or targets or that are not regular dependencies?

[weihanglo]

Maybe in case cargo tree prints nothing, it could print a helpful message suggesting to pass --all-features or --target all or -e ... to enable dependencies that require specific features or targets or that are not regular dependencies?

Great suggestion! I thought of the same thing when trying to fix #10593. It also makes me recall this cargo why proposal (#10006). Either way, we do need to make the current situation better. Personally, I'll suggest anyone what to help should follow what you propose first :)

[weihanglo]

If anyone wants to add a useful message for this issue, check these possible steps:

1. Check the length of root_indexes here.
2. If it is not empty, then we shall be fine to call print.
3. If it is empty, print a warning via ws.config().shell().warn(…). The error message could be

   nothing to print.
   
   To find dependencies that require specific features or target platforms, try use options `--all-features` or `--target all` first, and then narrow your search scope accordingly.
   

   The error message I provide is not ideal and needs a polish, though.
4. Add some tests under tests/testsuite/tree.rs.

I believe it is the only scenario that cargo-tree prints nothing if the length of root_indexes is zero. You could play with other combinations of tree options to prove it :)