display indirect dependency chain for incompatible crates

[zdenek-crha]

I've run lichking check on my crate and it found depencency with incompatible license. Since it is not direct dependency, I've tried to find how it comes into my project and failed. The cargo tree does not show it at all, yet lichking is able to find it.

Reproduction

My project is not public yet, but reproduction can be done on lalrpop v0.18.1. Running check tells us that arrayref is not compatible:

$ cargo lichking check
 ERROR cargo_lichking::check > lalrpop cannot include package arrayref, license BSD-2-Clause is incompatible with MIT / Apache-2.0
 ERROR cargo_lichking        > Incompatible license

Using cargo tree to find where it comes from gives nothing:

$ cargo tree | grep arrayref
... no output ...

$ cargo tree --all-features --edges all | grep arrayref
... no output ...

$ cargo tree --all-features --edges all --invert arrayref
... no output...

Since cargo tree does not see the arrayref as dependency of lalrpop project, where the lichking gets the information?

It might be good idea to introduce --verbose (or similar) parameter to check command that would display name of the crate with incompatible license together with dependency chain that lead to its inclusion into project.

[Nemo157]

lichking is using cargo metadata to get the info, but there's definitely the chance it's over-zealous in which packages it pulls out of that.

With cargo metadata --all-features | jq '.packages[] | select(.name == "arrayref")' you can see that the arrayref package is known within the context of the lalrpop build for some reason. Using some more jq hackery on the cargo metadata output I could eventually find:

> cargo tree --target x86_64-unknown-redox -i arrayref
arrayref v0.3.6
└── blake2b_simd v0.5.10
    └── rust-argon2 v0.7.0
        └── redox_users v0.3.4
            └── dirs v1.0.5
                └── term v0.5.2
                    ├── ascii-canvas v2.0.0
                    │   └── lalrpop v0.18.1 (/tmp/tmp.gzwDcAI4ZG/lalrpop-0.18.1)
                    └── lalrpop v0.18.1 (/tmp/tmp.gzwDcAI4ZG/lalrpop-0.18.1)

So I think the difference here is that cargo-lichking is target-agnostic, it checks all possible targets, while cargo tree is limited to displaying the tree for a single target at a time. Which is something that cargo-tree was actually better about supporting:

> ~/.cargo/bin/cargo-tree tree --all-targets -i -p arrayref
arrayref v0.3.6
└── blake2b_simd v0.5.10
    └── rust-argon2 v0.7.0
        └── redox_users v0.3.4
            └── dirs v1.0.5
                └── term v0.5.2
                    ├── ascii-canvas v2.0.0
                    │   └── lalrpop v0.18.1 (/tmp/tmp.gzwDcAI4ZG/lalrpop-0.18.1)
                    └── lalrpop v0.18.1 (/tmp/tmp.gzwDcAI4ZG/lalrpop-0.18.1) (*)

I definitely think having some sort of debugging output for this sort of thing would be nice.

[Nemo157]

Oh, turns out cargo tree does support it, it's just undocumented 😁

> cargo tree --target all -i arrayref
arrayref v0.3.6
└── blake2b_simd v0.5.10
    └── rust-argon2 v0.7.0
        └── redox_users v0.3.4
            └── dirs v1.0.5
                └── term v0.5.2
                    ├── ascii-canvas v2.0.0
                    │   └── lalrpop v0.18.1 (/tmp/tmp.gzwDcAI4ZG/lalrpop-0.18.1)
                    └── lalrpop v0.18.1 (/tmp/tmp.gzwDcAI4ZG/lalrpop-0.18.1)

[zdenek-crha]

@Nemo157 That is an excellent new. In that case it might be sufficient to just add 'how-to' into lichking documentation?
I mean, it sure would be nice and helpful feature, but if cargo tree can provide this information, its priority would be be that high.