`cargo add <name>@latest` support

[epage]

Problem

cargo add allows modifying an existing dependency entry, changing the version req (cargo add <name>@<version-req>), adding features, etc. Two things lacking

• There isn't a way to force using a dependency from a registry (cargo add <name> will fallback to the registry if something better doesn't match)
• There isn't a way to edit a version-req to the latest without pre-knowing the latest

Proposed Solution

Other ecosystems have a latest label that is a stand-in for the registry's highest version requirement for the package

• go get <name>@latest
  • See go get documentation
  • They also support none for removing (instead of separate cargo rm), upgrade for a form of semver-compatible changing of version requirement. See https://go.dev/ref/mod#version-queries
• poetry add <name>@latest
  • See poetry add documentation

Notes

This does not replace the need for bulk-upgrading, see https://github.com/rust-lang/cargo/issues/10498

[joshtriplett]

I personally would spell this cargo update -p somecrate -s to upgrade to the latest compatible version, or cargo update -p somecrate -i if wanting to upgrade to the latest version ignoring compatibility. I don't think this should go under cargo add.

[lgarron]

Coming from https://github.com/rust-lang/cargo/issues/12331#issuecomment-1642553762 to indicate my support for this!

I use @latest frequently with npm. There's plenty of cognitive friction between different ecosystems, but there would be one less if cargo also supported this!

[epage]

Is it purely from muscle memory that you want to use @latest or is there a change in behavior, for example

• Sometimes cargo add will try to reuse an existing version within your project (version from a dev-dependency in a dependency, use a workspace dependency rather than regular, etc)
• cargo add also lets you modify existing entries. cargo add foo@latest would allow updating foo

If for muscle memory, the part that seems odd to me is that @latest is a lot more to type.

[lgarron]

It's from dealing with over half a dozen package managers that all do things slightly differently:

• install vs. add (where install has multiple meanings sometimes)
• upgrade vs update
  • And npm notoriously doesn't have a way to properly update either all deps, or a specific transitive dep — necesssitating separate tools like: https://www.npmjs.com/package/npm-check-updates
• Different fetching/caching/global installation rules.

As a matter of UX, I think there's not a lot of value in understanding and memorizing these nuances — I just want to install/update a package and keep coding.

For example: when I publish a package and then immediately use it in another project, @latest tends to be the most reliable for me (at least when using npm). There might be another way, but this way is explicit and clear — if the command succeeds, I should now have the latest version. I'd love it if I could do the same with cargo instead of having to remember whether it's done differently. One less thing to stumble over while trying to have a productive coding session. 🤓

[epage]

As a matter of UX, I think there's not a lot of value in understanding and memorizing these nuances — I just want to install/update a package and keep coding.

This actually makes me hesitant to move forward with this. A cargo add foo@latest would have different semantics than cargo add foo and when those differences would show up, you should probably be using cargo add foo unless you are making a very conscious choice. If supporting cargo add foo@latest is for unconscious choices then that is leading people down the wrong path and would be a bad UX.

[lgarron]

I keep running into this. I can't figure out how to do this using cargo update or cargo add, and Google is useless: https://www.google.com/search?q=cargo+update+a+dependency+to+the+latest+version

At this point I'm trying to address security vulnerability alerts by removing packages from Cargo.toml one-by-one and adding them back from scratch using cargo add.

[epage]

cargo add and cargo remove were merged in from a bundle of tools called "cargo-edit". We haven not yet merged cargo-upgrade but you can cargo install cargo-edit to get it. FCP for #12425 is about to close after which we'll have a subset of cargo upgrade directly in cargo update.