Print all features when the verbose flag is set

[tcanabrava]

Currently, the dependency printing has a hardcoded limit, and for some crates it's useful to see a bit more. I understand why the hard limit is set, but we already have a verbose flag, let's use it and let the user decide if he wants to see something more.

My case was the crate reqwest, that listed for me as:

➜  cargo add reqwest
    Updating crates.io index
      Adding reqwest v0.12.15 to dependencies
             Features:
             + __tls
             + charset
             + default-tls
             + h2
             + http2
             + macos-system-configuration
             26 deactivated features

What are those deactivated features? I had to use the browser to discover, whereas it's much more confortable for me to just do a small pipe to grep and - to see only the features I care about: the ones that are disabled, and I might need to add to my project.

Overall, this is a really small change, but made my life easier.

now, with cargo add reqwest --verbose I can properly see all deps.

[rustbot]

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[epage]

This is being discussed in #15178. In it, I brought up the idea of raising the cap. I would like to focus on figuring out what the cap should be before we do this.

[tcanabrava]

This is being discussed in #15178. In it, I brought up the idea of raising the cap. I would like to focus on figuring out what the cap should be before we do this.

I believe no amount of cap raised would be correct (with this we can always | grep, with cap we will never be sure if it's hidden. specially because the cap is not displayed when we are running cargo.

on a second note, this makes cargo add in feature parity with cargo info, that has a working --verbose for the features of a crate, but the output is slightly more convoluted.

[epage]

I believe no amount of cap raised would be correct (with this we can always | grep, with cap we will never be sure if it's hidden. specially because the cap is not displayed when we are running cargo.

My interest in focusing on the caps is for social, and not technical reasons. If we have a bad default, feedback will be rare with a trivial workaround.

on a second note, this makes cargo add in feature parity with cargo info, that has a working --verbose for the features of a crate, but the output is slightly more convoluted.

cargo info serves a different role. It is intended for showing you data about a package. Here cargo add is trying to provide context for the performed operation but that should no be at the cost of the operation.

That said, I'm overall fine with showing all features with extra verbosity (though I do wonder if that should be a "extra verbose" setting). My priority is just on the defaults.

[tcanabrava]

That said, I'm overall fine with showing all features with extra verbosity (though I do wonder if that should be a "extra verbose" setting). My priority is just on the defaults.

I believe the defaults can be changed, and my MR could still be in. As the defaults is not what would happen with --verbose, it's what happens without it.
Both things can coexist :)