cargo add: Show features that were explicitly enabled

[Aloso]

Problem

cargo add can be used to enable features of an existing dependency. In that situation, it's useful to see which features were enabled explicitly, i.e. are listed in the Cargo.toml file.

Proposed Solution

In the list of features, add the text (enabled explicitly) after explicitly enabled features:

cargo add once_cell -F parking_lot,unstable
    Updating crates.io index
      Adding once_cell v1.11.0 to dependencies.
             Features:
             + alloc
             + parking_lot (enabled explicitly)
             + parking_lot_core
             + race
             + std
             + unstable (enabled explicitly)
             - atomic-polyfill

Another possibility is to only show this with the --verbose/-v flag, but I think it's useful enough that it can be shown always.

Notes

No response

[epage]

While we shouldn't show state exclusively through formatting, we could also bold these items.

[epage]

In terms of intended use cases, this is a bit lower in the priority list for cargo-add

1. Add a new dependency: they user knows what was explicitly enabled, we don't have to tell them
2. Run a command from documentation and it just works regardless of the existing manifest: they just want it to work, knowing exactly what happened doesn't matter
3. Switch back and forth between registry and git dependency: features aren't as relevant
4. Be a feature editor: this is the case where knowing the state of the manifest is more important

[epage]

In doing this, we might also want to explicitly list a default feature to show whether it is explicitly enabled or not.

[marcospb19]

I'm taking my shot at this one.

[weihanglo]

@marcospb19 Please note that this is still in discussion, so probably better sharing your idea before filing a pull request.

[Aloso]

@weihanglo where is that discussion taking place? If there are any concerns, I would like to know about them. I assumed that the "Proposed Solution" in my issue would be uncontroversial, because there was no feedback here suggesting otherwise.

[weihanglo]

I don't really have a strong preference at this moment. Just need to weigh on the complexity added and the value gained. Perhaps the implementation turns out to be quite simple! @epage may have more thoughts since he commented #10681 (comment).

That said, it's always worth an exploration if someone wants to deep dive into the codebase.

[epage]

@Aloso lack of feedback is not consent for change. For non-trivial Issues, we label them as S-accepted when we've decided we are on board with it.

For me, this is a lot of visual noise with lower value and I lean against making the change, especially when we have other information we might want to display in the future, like features that are unstable which deserve more visual attention.

I'm also not really seeing the need for reporting which features were enabled explicitly

[Aloso]

@epage thank you for elaborating, I appreciate the feedback.

[marcospb19]

I think the original proposal adds visual noise, but it can be improved so I'd love to discuss more what we're trying to achieve and how to best achieve that.

I'm also not really seeing the need for reporting which features were enabled explicitly

I use cargo-add a lot and its output always gets me confused due to the nature of crate features:

1. Some features enable other features (implicit features).
2. Crates can enable other crates' features.
3. Default feature lists might be toggled off.

I like to reduce the number of features and crates in order to decrease compile time and workspace folder size, so I always ask myself some questions:

• Can I remove this feature?
  • What enabled it in the first place? Was it enabled ...
    • by another feature?
    • by default?
    • by me explicitly?
    • by another crate?

I usually go to docs.rs or read the source code to answer these questions, but I think cargo-add could answer it right away.

I also ask "How many (and which) dependencies did this feature add?", even though I don't want cargo-add to answer this directly, answering the above questions would give me a shorter investigation path to figure it all out.

About implicit features: they obfuscate the rest of them while being mostly useless, and most people don't know about them (especially beginners), if cargo-add marks them that would change (lots of people are using cargo-add) and I believe it would help the ecosystem migrate to the new dep: syntax.

Motivation

My main motivation is providing an easy path to achieve lower compilation times and avoid compiling/checking/linting on unused crates, but understanding how a crate structures its features (and deps) is very helpful for countless reasons.

Brainstorming a solution

I don't know if that's something for cargo-add to solve or if we'd prefer in another subcommand.

But here's an uglier and arguably more useful output example:

Explicitly enabled features:
 + serde
 + small_rng
Enabled by default:
 + std
 + std_rng
 + getrandom
 + rand_chacha
 + alloc
Implicitly enabled by other feature:
 + example1
 + example2
Disabled features:
 - log
 - min_const_gen
 - nightly
 - packed_simd
 - serde1
 - simd_support

(I'd expect the "Implicitly enabled by other feature:" section to not be present most of the time, as crates start using the new feature-dep syntax)

How it looks like in the terminal:

That's just an example to show how it could be done without introducing too much visual noise.

Any thoughts?

[epage]

Can I remove this feature?

I think this is a good sign we might be using the wrong tool. cargo add cannot remove features and isn't meant to be a general viewer for analyzing them so if someone is trying to optimize for that, we probably should look else where, like #948