I was hoping we could recommend aliases for working around the need for -Z but processing of aliases happens after + toolchain selection, so we can't. The next best horrible option is to do it in your shell.
I don't feel a big hurry because, honestly, I don't use cargo-edit. My work on this started more from the perspective of finding areas of high-demand but unfinished cargo work and help it get over the edge. However, the reason I don't use cargo-edit is an anecdote in favor of getting it sooner than later: its because its not been built-in and its one of those quality of life improvements that the effort to install just never seemed worth it but having it integrated, it would be worth it. In effect, I'm doing this work so I will start to use cargo-edit.
I can see the value for waiting. As a parallel, it always feels weird when I see a crate go "1.0" and do major breaking changes. In our case, a lot of this is fairly solid feedback with existing precedence and anything controversial is being put behind a gate or removed. I also need to rewrite cargo-add to fit within cargo and the gap between solidifying the UX and being merged will help. I intentionally started with the UX improvements before porting so (1) we can get feedback and (2) the rewrite will just be implementation details.
It is also unclear how much feedback we'd get from waiting. cargo-add hasn't been getting much feedback in the time I've been involved. The lack of feedback could in part be from the lack of involvement from maintainers before I got involved.
This could be worthwhile but it'd be work. I'm going to be forking the cargo-add code base to merge it into cargo. We'll be having to keep two distinct code bases in sync with each other.
I'm not a fan of +feature. It's a unique microsyntax, close to rustup's +toolchain (cargo +nightly add != cargo add +nightly), and I don't think it will be discoverable.
Cargo already has --features, and I prefer consistency over saving keystrokes. I use cargo test --features=foo,bar often, so cargo add --features=foo,bar seems natural to me. I presume cargo test +foo +bar isn't going to work, so the +feature would be just for this one command.
The + syntax isn't self-explanatory, so in documentation where I recommend users add my crate with features, I'll continue use the explicit version.
I would like to have some syntax to mean "use default features, except the ones specified" (e.g. disable the std feature). This will need a new feature syntax in Cargo. Something like --features=-std could work, but then it would not work well with bare -std or +-std. So I think it's best to leave out clever new feature syntax for now to leave room for future expansion.
Keep in mind it won't be cargo add +nightly but cargo add foo +nightly (for the rare times crates have a "nightly").
While this has the side benefit of saving keystrokes (which is a big benefit, people have been eager for a feature shorthand), the motivating benefits were
Single-line "getting started"
Being able to post this in docs:
$ cargo add serde +derive serde_json
While I know there is the concern about understandability for users, it is much more likely for someone to offer a single-line for getting started than having to document
Provide + to reduce the need to understand modality (proposed)
Provide + and completely remove single-add mode
We should be weighing impact of understanding modality vs understandability of the + syntax.
While +derive is more understandable in a command for features, I think a simple example in --help will clarify the intent in the code because people are used to a derive feature. The main impact will be people completely new to Rust and people starting from the docs and trying to understand the docs vs a blind template. This doesn't mean there is no impact; I'm just trying to frame the impact.
Honestly, I think the 2-line version is way better. The crate names used form a column visually, so it's easy to see at a glance what these commands do. OTOH with the microsyntax feature names mixed with crate names make both unclear. If there were more crates I'd prefer multi-line list than a one wrapping line.
I also find it odd that the syntax is serde +derive ("serde" "+derive") in two arguments, rather than one argument per dependency. I'd expected it to be like Cargo's existing package spec syntax, which is one string with its own syntax, rather than multiple command arguments. Does serde @1 work the same way? I presume not, and serde@1+derive is ambiguous. So it's an odd multi-argument mix where space before version is forbidden, but space before a feature is required.
Hmm⌠additional effort for keeping diverging code bases in sync seems maybe a bit pointless. Iâm not sure about all the technicalities here, could perhaps a cargo-addu tool be created simply as a simple wrapper around a call to cargo +nightly add with unstable options activated? (It may as well additionally print a warning message that it can change or break in the future due to relying on unstable cargo features.) Sure cargo(stable)-calls-âcargo-adduâ-calls-cargo(nightly) is a bit messy, and one would need to make sure to provide reasonable error messages e.g. when no nightly toolchain is installed; but it seems better than the âyouâll need to write your own shell scriptâ approach.
Not that it matters publicly, but you can provide an array of chars to str::split. Thank you, though! I very much look forward to having this work in the manner I expect.
I can understand that. It'd would help if this feedback is verified by trying out in practice. Sometimes giving an honest attempt changes our minds, sometimes it doesn't.
I am keeping this feedback in mind though I also know we can't satisfy everyone and we'll need to weigh out the feedback from a variety of people with overall design goals.
That said, there is another route we can explore depending on the reception
Add a short flag for feature (and have approval of that act as as a proxy for approving it for all of cargo)
Make the various crate flags position-sensitive. Clap tells us the relative position of each occurrence of a flag so we can map flags to crate names.
e.g. cargo add serde -F derive serde_json would be like cargo add serde +derive serde_json
We would have a more explicit and more complete version of + arguments and completely remove modality. It would come at the cost of increased implementation complexity and any potential user confusion due to the rarity of position-sensitive flags.
-F is in and its just a short flag for --features. Both accept space separated (requires quotes) or comma separated list of features like other cargo commands.
I have not implemented position-sensitivity yet, waiting to see how the reception is, especially from those who are concerned about +.
I think -F derive serde_json is a better idea than +derive serde_json syntax. Thank you for your hard on making cargo-add better.
Edit: updated for clarity.
I just want to make sure we are on the same page. Are you saying just -F is better or are you also referring to the proposal for position-sensitive arguments?
Speaking about the cargo add serde +derive syntax: looks like only pip has prior art for that (of the add commands listed in the initial post) and uses package[some,extras] for that. Maybe something like that should be considered
# Positive
cargo add serde[derive] serde_json
# Can be extended to negative too
cargo add nom[-std,alloc]
One thing that came up recently: if a crate depends on A which depends on older, semver-incompatible version of B then cargo add B should use the version that's already in the crate tree for two reasons: de-duplication of code and avoiding compatibility problems. Obviously this would require cargo add to update Cargo.lock which I'm unsure if it's acceptable.
I'm raising it here because I suspect it should be the default behavior (opt-out, not opt-in).
I disagree. In particular, âavoiding compatibility problemsâ only makes sense if the transitive B dependency is a public dependency of crate A anyways, and the public vs. private dependency distinction is not something that cargo can automatically detect/understand. And private dependencies are, well, private not only because someone arbitrarily decided to arbitrarily use the âpublic/privateâ terminology here to distinguish two things that need to be distinguished when you talk about semver-compatibility, but also because theyâre actually supposed to be private in the sense of encapsulation, where private dependencies should not affect the users of a crate.
I imagine that it could get very annoying for crate maintainers (of a crate A with a private dependency on crate B) being annoyed by users âplease update your B dependency because it negatively affects my cargo add behaviorâ.