Support a shorthand for specifying features when cargo adding multiple crates

[kotx]

Problem

cargo add can be a bit annoying when specifying features for multiple crates. For example:
cargo add serde sqlx --features serde/derive sqlx/postgres fails with error: invalid character `/` in dependency name: `sqlx/postgres`, characters must be Unicode XID characters (numbers, `-`, `_`, or most letters)

It's necessary to use one of

$ cargo add serde --features serde/derive sqlx --features sqlx/postgres
$ cargo add serde -F serde/derive sqlx -F sqlx/postgres
$ cargo add serde sqlx -F serde/derive,sqlx/postgres
$ cargo add serde sqlx -F "serde/derive sqlx/postgres"

But those methods are also cumbersome in having to specify the crate name multiple times

Proposed Solution

It would be useful to have a shorthand for specifying features, whether

• Like pip extra's: cargo add serde[derive] sqlx[postgres,sqlite]
  • If we're daring maybe even cargo add sqlx[-default,postgres,sqlite]
• Like cargo feature or the cargo-edit version of cargo add: cargo add serde +derive sqlx +postgres +sqlite
• Allowing bare feature names when unambigious: cargo add serde -F derive sqlx -F postgres -F sqlite

Notes

No response

[epage]

For background, before dep/feature was allowed with add, an alternative syntax was proposed, see killercup/cargo-edit#592. For more history on it see

• https://internals.rust-lang.org/t/feedback-on-cargo-add-before-its-merged/16024
• feat: Import cargo-add into cargo #10472
• https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/Stablizing.20cargo-add

In summary, the main reason we removed it was cargo add was going to be insta-stable due to having higher precedence than cargo-edit and we wanted the initial release to be more conservative, so we only focused on --features (and added the -F shorthand) which is consistent with the rest of cargo.

[kotx]

You can also do

$ cargo add serde sqlx -F "serde/derive sqlx/postgres"
$ cargo add serde sqlx -F serde/derive,sqlx/postgres

A space in argument values needs to be quoted but , is supported as an alternative separator.

@epage That sounds better, but it's still not possible(?) to specify both crate name and feature in one go, i.e. the crate name is still required twice. Would like a way to specify a crate with features just so it's faster, since I create new crates quite often.

In summary, the main reason we removed it was cargo add was going to be insta-stable due to having higher precedence than cargo-edit and we wanted the initial release to be more conservative, so we only focused on --features (and added the -F shorthand) which is consistent with the rest of cargo.

This makes sense, but I want to ask, is the new functionality proposed here or the +feature syntax possible for a future release or is a decision still pending?

[epage]

@epage That sounds better, but it's still not possible(?) to specify both crate name and feature in one go, i.e. the crate name is still required twice. Would like a way to specify a crate with features just so it's faster, since I create new crates quite often.
...
is the new functionality proposed here or the +feature syntax possible for a future release or is a decision still pending?

Still pending. We have not brought the subject up again.

For myself, I would want to a better idea of the scope of people who are wanting to do these more involved cargo add commands. My assumption is that in the majority of cases, it'll be copy/paste from documentation and a minority of times it will be by users. If the scope is small enough, it might not be worth providing a shorthand. Some of this will require time of cargo add being out there and being used.

[kurtbuilds]

I implemented the cargo add crate1 +feat1 +feat2 crate2 syntax in a fork.

https://github.com/kurtbuilds/cargo

If there's interest, I can create a PR to merge.

[epage]

We are not blocked on implementation (this previously existed in the cargo-add version). See my previous comment

is the new functionality proposed here or the +feature syntax possible for a future release or is a decision still pending?

Still pending. We have not brought the subject up again.

For myself, I would want to a better idea of the scope of people who are wanting to do these more involved cargo add commands.

[kornelski]

serde/derive shortcut seems quite nice, since that's the Cargo's internal syntax too, so the syntax should be recognizable. It wouldn't cause confusion when people try to use the CLI syntax in their TOML syntax.

Multiple features could be specified by repeating the crate name (again same as [features]) or just left out for -F to handle.

[woile]

Is this ticket still relevant? I'm able to install packages and features like this:

cargo add thiserror tokio argon2 axum-extra tracing tracing-subscriber serde secrecy \
    -F 'serde/derive' -F 'secrecy/serde' -F 'tracing-subscriber/env-filter' -F 'tokio/full' \
    -F argon2/std -F axum-extra/cookie -F axum-extra/cookie-signed

It would be nice to provide an example on the cargo add page for multiple crates with multiple features

[epage]

Is this ticket still relevant? I'm able to install packages and features like this:

This issue is about having a short hand

It would be nice to provide an example on the cargo add page for multiple crates with multiple features

We do have cargo add serde serde_json -F serde/derive. The question from there is how many cases should we support. The existing examples shows how to do it and that it is using existing cargo syntax.