cargo
cargo copied to clipboard
rust-lang
Add `--all-features` to `cargo add`
Problem
Sometimes, I want to add a crate and blindly enable all the features. For example, Nix puts almost all the interfaces behind at least 1 feature gate, to use an interface, one has to enable the corresponding feature, which is good for reducing the compilation time.
But there are cases where I don't want to bother with that, it is a pain to open the doc, and figure out the feature name used by the interface I want to use and enable it.
If cargo add has a --all-features flag, then I can just enable all the features with it.
Proposed Solution
If would be nice if --all-features could be supported by cargo add, i.e., add the dependencies and enable all their features.
One alternative way to solve the issue is to provide a full feature in Nix, like tokio does, so that I can:
$ cargo add nix --features full
Notes
No response
Just check the original cargo-edit before it got moved into cargo. It didn't have the --all-features flag as well, so I guess we just never though of that.
Would you mind sharing more on the use cases you have? It is helpful for us to think through them and might come up other creative alternatives.
Hi, thanks for the reply!
Would you mind sharing more on the use cases you have?
Currently, the only usage I have is the one described here
When talking about the responsibility of managing features, it makes more sense that a crate provide a full feature, so that Cargo won't activate any two features that are incompatible with each other. However, if we want to maintain the consistency across Cargo commands, it seems better to have the --all-features flag.
Running into this and would be a +1 for the cargo add [name] --all-features since it feels more naturally consistent, and it's clearer what it's doing from the cargo side.
After discussing this as a team, we have decided we are going to close this.
Dependency specifications include a version requirement which is a range of versions, rather than a single version. When validating features, we select the oldest version that matches the version requirement for maximum compatibility with all versions in the range. That could also be done for --all-features but then its name is a bit misleading.
There are also many situations where all-features shouldn't be added and optimizing for this workflow could lead to unintended behavior. We make it appear that this is an expected path and users will follow it, whether they know the risks of not. When they hit a problematic case, they will have a frustrating experience working through it. Then the maintainer will have a frustrating experience supporting their users. This could lead to maintainers assuming that their package should be made safe for --all-features which isn't necessarily the case and constrict the design choices the maintainer could make.
Examples of features we shouldn't automatically enable without a second thought:
debugfeaturestestfeaturesunstable-*features (which we want to have built-in support)_*private features (which we want to have built-in support)nightlyfeatures- mutually exclusive or subtractive features (though these are also discouraged)
cargo add is also primarily focused on initially adding dependencies at which point in time you are unlikely to know about the full feature set. Being able to operate as a feature editor comes second which is why there isn't support for removing features. The primary reason it can somewhat operate as a feature editor is we tried to design it to be idempotent so you can copy/paste commands without concern with what is already in your manifest.
