Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for working with features #193

Closed
adeschamps opened this issue Jan 20, 2018 · 6 comments
Closed

Support for working with features #193

adeschamps opened this issue Jan 20, 2018 · 6 comments

Comments

@adeschamps
Copy link

adeschamps commented Jan 20, 2018

I have two features I'd like to propose:

The first is the ability to specify features when adding dependencies, with a -F or --feature flag that can be specified multiple times:

$ cargo add serde_json --feature preserve_order

The second is ... split into #529

@ordian
Copy link
Collaborator

ordian commented Jan 20, 2018

Thanks for the suggestion!

I guess listing features was implemented some time ago, but we've removed the cargo list subcommand in #130.

It seems like a useful addition to me, let's see what @killercup and @bjgill think.

What is not clear is whether we should list aliased features as well, e.g. in semver's Cargo.toml serde feature is not listed directly, so in your example the output would be something like (num-complex/serde is not listed):

$ cargo add nalgebra --features "abomonation-serialize"
      Adding nalgebra v0.13.1 to dependencies
      Features:
             + abomonation
             + abomonation-serialize
             - arbitrary
             - debug
             - serde
             - serde-derive
             - serde-serialize

Also we should follow cargo in specifying multiple features.

@adeschamps
Copy link
Author

Good point about the syntax for specifying multiple features.

Sometimes I see optional dependencies that probably wouldn't work right if you enabled them individually. For example, serde and serde-derive might be grouped together under a single feature like in that example.

My inclination is to list both the features and the optional dependencies themselves, but with some indentation to indicate how they're grouped together. (I'd make an example if I wasn't on my phone)

I'd be happy to implement this. I looked at the code, and it seems fairly straightforward.

@ordian ordian added this to the 0.3 milestone Jun 7, 2018
@Boscop
Copy link

Boscop commented Sep 8, 2019

Any update on this?
How about:
cargo feature <crate> +<feature1> -<feature2> (adding feature1 to crate, and removing feature2).

So it'd be:
cargo feature serde_json +preserve_order

I guess, removing features will rarely be done (would be acceptable to have to use an editor for that), so maybe the following syntax would be better:
cargo fadd <crate> <feature1> <feature2> ..
So:
cargo fadd serde_json preserve_order

The syntax shouldn't be too verbose (not requiring writing --feature).

@SOF3
Copy link

SOF3 commented Mar 25, 2020

Without considering default-features, this syntax is consistent with the features.*[*] format of Cargo.toml and should be backward-compatible:

# this appends `serde = {version = "x.y.z", features = ["derive"]}`,
# or edits the existing entry with the feature added
cargo add serde/derive

# if existing entry is  serde = {version = "x.y.z", features = ["derive"]}`,
# this will only remove the feature without removing serde
# if the existing entry does not have the derive feature, we abort with eror
cargo rm serde/derive
# this adds any missing features among serde/derive and serde/rc without errors
# (but might warn if exists)
cargo add serde/derive serde/rc

@SOF3
Copy link

SOF3 commented Mar 25, 2020

As for default-features, I think it makes sense for anyone who wants to have more complex argument lists to be in separate command.

@epage
Copy link
Collaborator

epage commented Oct 14, 2021

Back when this issue was created, it doesn't look like we supported any way of specifying features. Since then, we have added --features which matches cargo. This resolves the first request.

The second request I split out into #529.

Since this seems resolved, going to go ahead and close this.

@epage epage closed this as completed Oct 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants