Feature request: Add features using crate+feat1+feat2 syntax.

[kurtbuilds]

Currently, users can specify features with the --features option, like so:

cargo add serde --features derive

I think it's much easier as an end user to remember a syntax like the following for adding features:

cargo add serde+derive

This supports multiple features, as in:

cargo add serde+derive+rc

This syntax has the additional benefit that users can associate features on a per crate basis, enabling invocations like this:

cargo add serde+derive serde_json

I implemented this in a fork: https://github.com/kurtbuilds/cargo-edit But it needs to be updated, as there are code conflicts now.

Is there openness to merging/re-implementing this feature into mainline?

It should be entirely backwards compatible, since the --feature can continue to be supported, and no packages have + in their name.

I know there's the cargo-feature tool, but it seems like a worse approach to have a separate invocation cargo feature ... when adding features vs adding packages.

[epage]

Its an intriguing idea, in particular because it allows you to add multiple crates (cargo add serde+derive serde_json). This could be a more barebones approach to #383.

One question I have is how to tell when a + is in a path or is for adding features. So let's look at the full syntax

{<path> | <name>[:<path>] } [+<feature>]...

We could do the equivalent of rsplit_once('/') and assume + in the last path component are features.

And one concern is if we are getting too magical / custom in syntax. We are working on finalizing the CLI for cargo which gives us less room for experimentation. We could put this behind an unstable feature flag.

[kurtbuilds]

Its an intriguing idea, in particular because it allows you to add multiple crates (cargo add serde+derive serde_json). This could be a more barebones approach to #383.

One question I have is how to tell when a + is in a path or is for adding features. So let's look at the full syntax

{<path> | <name>[:<path>] } [+<feature>]...

We could do the equivalent of rsplit_once('/') and assume + in the last path component are features.

Yeah, I think your solution makes sense. Crates are forbidden to have + in the name, so any + there is either user error, or if this was implemented, would be a feature.

It would prevent something like cargo add ormx+sqlx/sqlite (where sqlite is a feature of the sqlx dependency of ormx). That seems esoteric enough to not be a blocker, as the user can fall back to cargo add ormx --features sqlx/sqlite.

Double checking, the current syntax doesn't allow for +<feature> right? It's <name | name:path> --features <feature>? That's an interesting idea which avoids the issue you brought up about filepaths. cargo add serde +derive +rc serde_json could be interpreted to apply those features only to the immediately preceding crate. It avoids the pathing problem you bring up, is backwards compatible (crates can't have + in the name), unambiguous, and I think equally readable (perhaps even a tad more so).

And one concern is if we are getting too magical / custom in syntax. We are working on finalizing the CLI for cargo which gives us less room for experimentation. We could put this behind an unstable feature flag.

That makes sense. If we get agreement on the syntax, whether with the space separator or the rsplit_once approach, it can be feature flagged if there's lingering concerns about possibilities for conflict.

[epage]

btw I posted on the internals thread for reviewing cargo-adds CLI about this proposal to solicit more feedback.