Limit the number of crate features that are displayed as result of `cargo add`

[ranile]

Problem

Some crates have way too many features (such as web-sys). cargo add lists every feature when adding a crate and could potentially even overflow terminal buffer (it just did for me with web-sys using console)

Proposed Solution

Limit the number of features that are displayed. The limit should preferably be configurable but a hard-coded one is also fine.

If the feature list is truncated, cargo should link to docs.rs feature list for that crate

Notes

No response

[weihanglo]

Sounds interesting. How bad is it now, could you share some screenshots?

[epage]

Following the link for web-sys

This version has 1566 feature flags, 0 of them enabled by default.

1566 is nuts.

I think, at minimum, we should show the enabled features. If so, we should make sure we indicate that it isn't all.

The question is how we should deal with this

1. First X entries with a "... X more entries"
2. First X entries, "... Y more entries", last Z entries
3. "... X more entries"

When the list is long like this, I feel like there is little value to first/last. The chance that any of those features matter is probabilistically small. I would lean towards Option 3 (only showing ...)

If the feature list is truncated, cargo should link to docs.rs feature list for that crate

1. We'd need to be careful that we detect for a crates.io package and decide on a fallback when its from a different source
2. Its still not guaranteed that the package will be there. crates.io first checks the if it exists before showing the link

We could generically link out to package.documentation, making the user figure out where to find the information.

Also, a link might be fairly long for putting in output mixed with text.

My proposal is that we use ANSI escape codes for embedding a link to package.documentation in the "X more entries" text. For terminals that support it, they get a helpful link. For everyone else, they will have to manually get the link but thats no worse off than if we don't provide it.

Short term, we should probably do this via fwdansi so we make sure it gets processed correctly (if fwdansi can handle it). Otherwise, we should wait until we switch to anstream (which I'm working on) so it will be handled automatically without any extra work.

If need be, we could decouple this link work from the rest of the work so we don't block the whole thing.

[epage]

If there aren't any concerns, my proposal is

• Hard coded limit of <50 features
• Always show enabled features
• If past hard limit, collapse all remaining features into "... X more features"
• Defer out including a link until anstream is in (ie create a separate issue to track that once this is closed as fixed)

I'm willing to help mentor someone on this so I've marked it as Accepted. You can reach me here, on zulip, or during office hours

[Angelin01]

@epage I think I could tackle this throughout this week and next week given some extra information and some style/convention guidance. I just have a few questions regarding your proposal:

• Always show enabled features

I understood this as "Show all enabled features regardless of the hard coded limit", but won't this lead to the same problem as this issue describes if someone enables a lot of features? If that's acceptable, then so be it.

Otherwise we could do something similar to what I propose below, just with a different message.

• If past hard limit, collapse all remaining features into "... X more features"

If I understood the above correctly, may I suggest renaming it to "... X more deactivated features"?
Also, do we print on the line with the - or after it?

      Adding example v0.1.2 to dependencies.
             Features:
             + activated1
             + activated2
             - deactivated1
             - deactivated2
             - ... 123 more deactivated features

vs

      Adding example v0.1.2 to dependencies.
             Features:
             + activated1
             + activated2
             - deactivated1
             - deactivated2
             ... 123 more deactivated features

We can also print "... 123 more active features" if we wanna collapse active features too.

I won't claim this just yet in case someone else can get to it before I do, but I'll try to get to it soon enough.

[epage]

I like explicitly stating "deactivating".

My assumption is someone won't have hundreds of activated features but I'm fine protecting against it by applying the limit to those as well and showing "X activated features\nX deactivated features".

I would assume the ... would not have a leading -. The - is a bullet and an indicator and it reads weird for ... to appear after the bullet

For myself, I don't see what benefit we'd be providing the user by listing some of the category that is collapsed (- deactivated 1). It takes up space and is just a fraction of the information so the chance of it being meaningful is relatively low. We're showing features to communicate what they activated and what they could activate and not a general feature viewer (that'd be more for a cargo info) .

[Angelin01]

@rustbot claim