Filtering crates by the nesting level

[Relrin]

Describe the solution you'd like I would like to have an overridable option in config / CLI which gives an opportunity to specify a maximum acceptable node level that can be captured and processed by the cargo-deny. It could be something like cargo-deny list --layout=crate --max-level=1, so that command will output / check the crates on root (defined in Cargo.toml) plus one level for each core dependency.

Describe alternatives you've considered Currently the desired group of the checked crates can be show with the usage of the grep command:

1. Do a regular call with CLI, for example cargo-deny list --layout=crate
2. Pass the output with | to the grep command with desired regular expressions / keywords.
3. Write the output into the file.

Additional context Let's look on the following example to get the whole idea. We want to output licenses of all core dependencies declared in the Cargo.toml. It could something like this (the output was taken for my own terraform-sage project):

=> cargo-deny list --layout=crate
aho-corasick@0.7.6 (2): Unlicense, MIT
ansi_term@0.11.0 (1): MIT
ansi_term@0.12.0 (1): MIT
atty@0.2.13 (1): MIT
bitflags@1.1.0 (2): MIT, Apache-2.0
block-buffer@0.7.3 (2): MIT, Apache-2.0
block-padding@0.1.4 (2): MIT, Apache-2.0
byte-tools@0.3.1 (2): MIT, Apache-2.0
byteorder@1.3.2 (2): Unlicense, MIT
cfg-if@0.1.9 (2): MIT, Apache-2.0
clap@2.33.0 (1): MIT
digest@0.8.1 (2): MIT, Apache-2.0
fake-simd@0.1.2 (2): MIT, Apache-2.0
generic-array@0.12.3 (1): MIT
handlebars@2.0.1 (1): MIT
hashbrown@0.5.0 (2): Apache-2.0, MIT
heck@0.3.1 (2): MIT, Apache-2.0
itoa@0.4.4 (2): MIT, Apache-2.0
// ... and many more

With the usage of the --max-level option (or any other desired name) the cargo-deny filters crates by the certain nested level, so that it will output:

ansi_term@0.11.0 (1): MIT
ansi_term@0.12.0 (1): MIT
atty@0.2.13 (1): MIT
generic-array@0.12.3 (1): MIT
handlebars@2.0.1 (1): MIT
// ... the rest of the group

[Jake-Shadle]

Are you interested in that flag only for the list subcommand or for check as well?

[Relrin]

Currently I'm mostly interested in this functionality for the list subcommand. But it could be used as a part of the check subcommand for sure :)

[Jake-Shadle]

Cool. Let me know if you have ideas for other improvements to the list subcommand, it was kind of added just because we have all of the information available and it was easy to add, but we don't really use that much ourselves so it hasn't gotten much attention.