-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
cargo add <name>@latest
support
#10741
Comments
I personally would spell this |
Coming from #12331 (comment) to indicate my support for this! I use |
Is it purely from muscle memory that you want to use
If for muscle memory, the part that seems odd to me is that |
It's from dealing with over half a dozen package managers that all do things slightly differently:
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, |
This actually makes me hesitant to move forward with this. A |
I keep running into this. I can't figure out how to do this using At this point I'm trying to address security vulnerability alerts by removing packages from |
|
Problem
cargo add
allows modifying an existing dependency entry, changing the version req (cargo add <name>@<version-req>
), adding features, etc. Two things lackingcargo add <name>
will fallback to the registry if something better doesn't match)Proposed Solution
Other ecosystems have a
latest
label that is a stand-in for the registry's highest version requirement for the packagego get <name>@latest
go get
documentationnone
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-queriespoetry add <name>@latest
poetry add
documentationNotes
This does not replace the need for bulk-upgrading, see #10498
The text was updated successfully, but these errors were encountered: