A way for users to bulk upgrade across incompatible versions #12425

epage · 2023-08-01T01:58:57Z

epage · 2023-08-01T02:03:00Z

Below is some background on what we are using to help come up with a design

Care Abouts

Priorities

Don't break behavior on cargo update
Don't write out incompatible Cargo.lock and Cargo.toml
Focus is on end-users solving common problems and not on being a general programmatic CLI that is meant to cover every case
Be predictable and understandable
- Can someone unfamiliar with Rust, reading a blog post, predict what different command invocations will do?
- Preference for not having too similarly named commands
When higher priorities allow, avoid errors that make users go "if you know exactly what I was asking for then why didn't you just do it?"; those are a sign of issues with the UX.
Don't be hassle when dealing with intentionally held back dependencies

Primary use cases:

Want to have simple workflow for "upgrade incompatible dependencies only".
Want to have simple workflow for bulk lock to latest compatible (already exists as cargo update)
(medium priority) Selective modify one dependency's version requirement to latest compatible, latest incompatible
(lower priority) Want to have simple-ish workflow for bulk upgrade to latest compatible
(lower priority) bulk upgrade all dependencies (could just be two command invocations)

Secondary use cases are:

Selective modify version requirement to user-provided value
Upgrade explicitly pinned version requirements

Some open questions we had

How do we tell when a renamed dependency like tokio_03 is pinned or not?
- We could just assume all renamed are pinned
- We could add a dependency field but I'm a bit leery of adding that kind of bookkeeping to the manifest
- We could force users to --exclude these dependencies but that might be a bit of a pain to always remember to do
- We could only skip renamed if multiple dependencies exist that point to the same package

Context

Currently, cargo update is focused solely on Cargo.lock editing

Spans entire dependency tree
Multiple versions of a package may exist, referenced by name@version
Deals with exact versions and not version ranges
Only affects you and not your dependents

Version requirement editing is different in that

Workspace members only
May want differences between members
Supports alternative names for packages
Affects dependents

And as a reminder of the CLI:

cargo update -p foo  # select a non-ambiguous `foo` and update it
cargo update -p foo@ver  # selects a specific `foo` to update
cargo update -p foo --aggressive  # also update dependencies
cargo update -p foo --precise <ver>  # select a specific version
cargo update --locked  # fail if the lockfile will change

Note: cargo add --locked will also fail if the manifest will change

Some design tools we can consider include

Renaming a command, making the old name an alias
- Even if there isn't a culture shift to use the new name, cargo <cmd> --help and cargo --list will point people to the new name
Versions without the build metadata field is a subset of version requirement syntax, we may be able to do some mixing of them
- Precedence: using the same foo@ver syntax for versions and version requirements
Minimal-version resolution being the default mode would make Cargo.lock mostly align with Cargo.toml, making it easier to conflate the two commands (whether merging them or keeping separate but de-emphasizing update)

Interjection

Through this, I realized that the core of my concern with our previous attempts at a single command is that it feels like we are shoehorning new behaviors into cargo update rather than making the behavior cohesive.

If I see a cargo update --incompatible on a blog post, can I predict what will happen if you do cargo update? No, because --save is needed to match behavior
We were trying to make --package be both for package IDs and dependency names to make some of the cargo upgrade workflows work
We were trying to overload --precise to allow control over version requirements

I also realized that my Windows Updates vs Windows Upgrades analogy for cargo update and cargo upgrade breaks down a little because cargo upgrade can do "upgrades" that are on the level of cargo update (say we call it cargo upgrade --compatible). The difference is in the target audience (yourself vs your dependents)

epage · 2023-08-01T02:04:45Z

Proposal: `cargo update` only changes version requirements as a side effect

The primary role of cargo update has been to update your active dependencies (ie Cargo.lock). We do not plan to change that role but give the user control to force it to update in situations that were previously unsupported, particularly updating the Cargo.toml if need be.

Behavior:

By default, only "safe" updates are allowed (today's behavior)
cargo update --incompatible / cargo update -i will force (ie update version reqs) update unpinned, incompatible versions (no other dependencies)
- Yes, this could potentially be called --breaking or something else. The name depends on what expresses the concept clearly especially in light of any pinning behavior we have
- Keeping -i unused would keep the door for a --interactive to be added
cargo update -p foo --precise ver will force the update to happen, only erroring if we can't (don't own relevant version reqs, is pinned), even if its incompatible but unpinned. Version requirement is only changed on incompatible.
- Maybe the error on pinned could be relaxed

Somewhere between deferred and rejected (speaking for myself): Support in cargo update for writing to the manifest for non-breaking changes, like bulk compatible upgrades of version requirements (ie a -save flag) which was one of our lower priority workflows. A --save flag is more about updating versions for your dependents, which while important for having valid lower-bounds on version requirements, doesn't fit with the existing model of cargo update. Maybe in the future we can find a way to express this in cargo update that fits with how it works or maybe another command can take on this role. We just aren't wanting to distract our efforts for handling most of the use cases to handle this one

While this tells a cohesive story, a part of me is somewhat concerned that this goes beyond the name update.

Potential related `cargo update` improvements

"Rename" --aggressive to --recursive (make --aggressive an alias for the new name) (fix(update): Clarify meaning of --aggressive as --recursive #12544)
Specialize the parsing of [email protected] so that foo@x will work so long as its unambiguous (which it should be), much like cargo install [email protected] supports auto-selecting the y and z fields (picks latest) (feat(pkgid): Allow incomplete versions when unambigious #12614)
Consider applying some of the output formatting from cargo upgrade into cargo update (feat(update): Tell users when they are still behind #13372)
- Provides some of the cargo outdated experience (Make cargo outdated part of cargo itself #4309)
- Is an alternative to warnings (cargo update should print warnings for incompatible candidates #7167)
Add a positional package argument to cargo update, removing the need for --package (fix(update): Make -p more convenient by being positional #12545)
- Should be safe because there are no trailing var args for a wrapped child process and no (and little chance of) flags that accept 0..=1 values

Alternatives

These are alternatives I had considered that help give an idea of what I mean by fitting into cargo.

cargo update always modifies Cargo.toml

This would be a breaking change
This would get in the way of people intentionally keeping separate versions from version requirements

We deprecate cargo update and a cargo upgrade always updates both files

This would get in the way of people intentionally keeping separate versions from version requirements

We migrate to minimal-version resolution by default

cargo update becomes less useful and we move it out of the spot light.
A cargo upgrade is added that is focused on editing version requirements

Separate commands for Cargo.lock (update) and Cargo.toml (upgrade)

Names don't clarify the role each fills
Much like Debian has apt dist-upgrade, maybe it could be cargo req-update?

Misc Notes

I don't see us making a distinction between default operator and ^ as we document them as being the same thing and sometimes people use ^ just because
We are erring on the side of needing cargo update && cargo update --incompatible vs cargo update --incompatible doing both as there are people who do want them separated and running two commands, while annoying, allows us to cover more use cases.

fix(update): Tweak CLI behavior ### What does this PR try to resolve? When looking at `cargo update` for #12425, I noticed that the two flags related to `--package` were not next to it or each other. I figured grouping them like that would make things easier to browse. When looking into that, I noticed that the two flags conflict and figured we'd provide a better error message if we did that through clap. ### How should we test and review this PR? Looking per commit will help show the behavior changes. ### Additional information I wanted to scope this to being simple, non-controversial, low effort, incremental improvements with this change so I did not look into the history of `--aggressive` not requiring `--package` like `--precise` does and figure out if there is any consistency we can be working towards.

epage · 2023-08-08T17:03:20Z

This proposal has been up here and on internals for a bit now without any major concerns raised.

@rfcbot fcp merge

rfcbot · 2023-08-08T17:03:21Z

Team member @epage has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

djc · 2023-08-08T19:02:39Z

Having been fairly involved in this discussion via the internals thread, I'm happy to see this move forward in a direction that I wholeheartedly support. @epage thanks for pushing this forward!

rfcbot · 2023-08-14T20:11:14Z

🔔 This is now entering its final comment period, as per the review above. 🔔

weihanglo · 2023-08-16T12:20:59Z

Can --incompatible be used in conjunction with --package?
Just recall #11974 and not sure about the implication of cargo update --incompat -p <pkgid>.

epage · 2023-08-16T12:51:16Z

Can --incompatible be used in conjunction with --package?
Just recall #11974 and not sure about the implication of cargo update --incompat -p <pkgid>.

Yes, we'd update the version requirement, if an incompatible version exists, and then run the normal code.

When working on cargo-upgrade, I found the meaning of `--aggressive` confusing and named it `--recursive` there. Renaming this in `cargo update` (with a backwards compatible alias) was referenced in rust-lang#12425.

MoSal · 2023-08-23T15:43:50Z

cargo upgrade can do "upgrades" that are on the level of cargo update (say we call it cargo upgrade --compatible). The difference is in the target audience (yourself vs your dependents)

This is probably stating the obvious. But if a dependency is imprecise, current cargo upgrade may have no effect where current cargo update would.

Let's say a dependency is serde_derive = "1" in Cargo.toml. And it's version = "1.0.183" in Cargo.lock. Then current cargo upgrade would change nothing locally, and wouldn't force dependants to get the latest version.

The separation of the tools and the clarity on each one's remit makes this, if not immediately predictable, at least easily understandable. But if this will no longer be the case, then this distinction, or a change from that behavior, should be made clear.

For what it's worth, I don't like this behavior, and I'll implement --force-precise for personal use. Especially since I only used imprecise deps in old projects.

epage · 2023-08-23T15:48:05Z

FYI on zulip I brought up the idea of a pedantic machine-applicable (ie --fixable) lint to flag imprecise dependencies.

Generally, cargo avoids positional arguments. Mostly for the commands that might forward arguments to another command, like `cargo test`. It also allows some flexibility in turning flags into options. For `cargo add` and `cargo remove`, we decided to accept positionals because the motivations didn't seem to apply as much (similar to `cargo install`). This applies the pattern to `cargo update` as well which is in the same category of commands as `cargo add` and `cargo remove`. Switching to a positional for `cargo update` (while keeping `-p` for backwards compatibility) was referenced in rust-lang#12425.

Generally, cargo avoids positional arguments. Mostly for the commands that might forward arguments to another command, like `cargo test`. It also allows some flexibility in turning flags into options. For `cargo add` and `cargo remove`, we decided to accept positionals because the motivations didn't seem to apply as much (similar to `cargo install`). This applies the pattern to `cargo update` as well which is in the same category of commands as `cargo add` and `cargo remove`. As for `--help` formatting, I'm mixed on whether `[SPEC]...` should be at the top like other positionals or should be relegated to "Package selection". I went with the latter mostly to make it easier to visualize the less common choice. Switching to a positional for `cargo update` (while keeping `-p` for backwards compatibility) was referenced in rust-lang#12425.

When working on cargo-upgrade, I found the meaning of `--aggressive` confusing and named it `--recursive` there. Renaming this in `cargo update` (with a backwards compatible alias) was referenced in rust-lang#12425.

Generally, cargo avoids positional arguments. Mostly for the commands that might forward arguments to another command, like `cargo test`. It also allows some flexibility in turning flags into options. For `cargo add` and `cargo remove`, we decided to accept positionals because the motivations didn't seem to apply as much (similar to `cargo install`). This applies the pattern to `cargo update` as well which is in the same category of commands as `cargo add` and `cargo remove`. As for `--help` formatting, I'm mixed on whether `[SPEC]...` should be at the top like other positionals or should be relegated to "Package selection". I went with the latter mostly to make it easier to visualize the less common choice. Switching to a positional for `cargo update` (while keeping `-p` for backwards compatibility) was referenced in rust-lang#12425.

loynoir · 2024-03-25T00:10:39Z

Keeping -i unused would keep the door for a --interactive to be added

Really hope --interactive.

yarn is one of the nodejs package managers, and it supports upgrade-interactive.

yarn 1

https://classic.yarnpkg.com/lang/en/docs/cli/upgrade-interactive/

yarn 4

https://yarnpkg.com/cli/upgrade-interactive

Not similar to cargo update, but similar to cargo-edit's cargo upgrade, but have a terminal ui.

For example, which supports

 Press <up>/<down> to select packages.            Press <enter> to install.
 Press <left>/<right> to select versions.         Press <ctrl+c> to abort.

? Pick the packages you want to upgrade.          Current          Range            Latest

 > @types/node --------------------------------- ◉ 16 ----------- ◯ 16.18.91 ----- ◯ 20.11.30 -----
   typescript ---------------------------------- ◉ 3.7 ---------- ◯ 3.7.7 -------- ◯ 5.4.3 --------

torhovland · 2024-05-28T11:05:10Z

I'm working on this. I should have a draft PR up soon.

epage · 2024-05-28T17:32:58Z

@torhovland which part of this are you working on? In a lot of ways, --precise vs --breaking are very different and I suspect they would best be handled as separate PRs.

Any high level details of what your understanding is for resolving the half you are working on?

torhovland · 2024-05-28T18:01:15Z

@epage I've been looking into --incompatible (--breaking).

So far I have introduced an ops::update_manifests() in front of ops::update_lockfile(). It reuses some code from cargo-edit to go through all dependencies, query latest versions, check if they are incompatible, update the manifest TOML if they are, then write the modified TOML to file. Then I'm simply resetting the workspace before calling ops::update_lockfile().

That is probably a little too simplistic, though. In particular, it won't work well with --dry-run, because ops::update_lockfile() will need the updated manifests. But maybe this can be improved so we don't have to reset the workspace. Also, I suppose we shouldn't do a full ops::update_lockfile(), but only update the dependencies that got modified by ops::update_manifests().

If you have any thoughts about this, feel free to share.

epage · 2024-05-28T18:21:01Z

The other problem with modifying the manifests before anything else is that we will leave the workspace in a half-updated state on failure.

My assumption was that we'd edit the Dependencys for workspace members (maybe all path sources?) and on success, we'd find all Cargo.toml all dependency blocks, including workspace.dependencies, and edit them then.

epage · 2024-05-28T18:23:17Z

. Also, I suppose we shouldn't do a full ops::update_lockfile(), but only update the dependencies that got modified by ops::update_manifests().

Yes, I believe the feature as specified says we shouldn't do compatible updates. We probably want the semantics of cargo check after editing Cargo.toml in case a requirement change causes a cascade of compatible updates.

torhovland · 2024-05-29T12:25:20Z

I submitted a draft PR now. I've changed the code so it can mutate the manifests without needing to write out intermediate files and resetting the workspace. But this means there are two kinds of manifest mutations going on, one for the manifests in memory, and one for preserving formatting when writing out modified manifest files. See the PR for details.

I haven't changed update_lockfile() yet.

I'll happily take any feedback.

Add `cargo update --breaking` Related to #12425. There are two kinds of manifest mutations here. In `upgrade_manifests` we have to mutate `cargo::core::manifest::Manifest` so that `resolve_ws` does what it needs to do, and outputs a correct lock file. Then, in `write_manifest_upgrades` we mutate `cargo::util::toml_mut::manifest::Manifest`, because that is how we can preserve the existing formatting in the manifest files on disk. Some of the code here is copied from `cargo-edit`. # Comparison with `cargo upgrade` Running on the Cargo source itself gives the following: ``` ❯ cargo upgrade --dry-run --incompatible allow --compatible ignore Updating 'https://github.com/rust-lang/crates.io-index' index Checking benchsuite's dependencies Checking capture's dependencies Checking cargo's dependencies name old req compatible latest new req note ==== ======= ========== ====== ======= ==== anstream 0.6.13 0.6.14 0.6.14 0.6.13 compatible anstyle 1.0.6 1.0.7 1.0.7 1.0.6 compatible anyhow 1.0.82 1.0.86 1.0.86 1.0.82 compatible itertools 0.12.1 0.12.1 0.13.0 0.13.0 libc 0.2.154 0.2.155 0.2.155 0.2.154 compatible opener 0.7.0 0.7.1 0.7.1 0.7.0 compatible openssl 0.10.57 0.10.64 0.10.64 0.10.57 compatible openssl-sys =0.9.92 0.9.92 0.9.102 =0.9.92 pinned pulldown-cmark 0.10.3 0.10.3 0.11.0 0.11.0 security-framework 2.10.0 2.11.0 2.11.0 2.10.0 compatible semver 1.0.22 1.0.23 1.0.23 1.0.22 compatible serde 1.0.199 1.0.203 1.0.203 1.0.199 compatible serde-untagged 0.1.5 0.1.6 0.1.6 0.1.5 compatible serde_json 1.0.116 1.0.117 1.0.117 1.0.116 compatible tar 0.4.40 0.4.41 0.4.41 0.4.40 compatible thiserror 1.0.59 1.0.61 1.0.61 1.0.59 compatible toml 0.8.12 0.8.14 0.8.14 0.8.12 compatible toml_edit 0.22.12 0.22.14 0.22.14 0.22.12 compatible unicode-width 0.1.12 0.1.13 0.1.13 0.1.12 compatible Checking cargo-credential's dependencies Checking cargo-credential-1password's dependencies Checking cargo-credential-libsecret's dependencies Checking cargo-credential-macos-keychain's dependencies Checking cargo-credential-wincred's dependencies Checking cargo-platform's dependencies Checking cargo-test-macro's dependencies Checking cargo-test-support's dependencies Checking cargo-util's dependencies Checking cargo-util-schemas's dependencies Checking crates-io's dependencies Checking home's dependencies Checking mdman's dependencies Checking resolver-tests's dependencies Checking rustfix's dependencies Checking semver-check's dependencies Checking xtask-build-man's dependencies Checking xtask-bump-check's dependencies Checking xtask-stale-label's dependencies note: Re-run with `--pinned` to upgrade pinned version requirements note: Re-run with `--verbose` to show all dependencies local: cargo unchanged: annotate-snippets, base64, bytesize, cargo-credential, cargo-credential-libsecret, cargo-credential-macos-keychain, cargo-credential-wincred, cargo-platform, cargo-test-macro, cargo-test-support, cargo-util, cargo-util-schemas, cargo_metadata, clap, color-print, core-foundation, crates-io, criterion, curl, curl-sys, filetime, flate2, git2, git2-curl, gix, glob, handlebars, hex, hmac, home, http-auth, humantime, ignore, im-rc, indexmap, jobserver, lazycell, libgit2-sys, libloading, memchr, miow, os_info, pasetors, pathdiff, percent-encoding, pkg-config, proptest, rand, regex, rusqlite, rustfix, same-file, serde-value, serde_ignored, sha1, sha2, shell-escape, similar, snapbox, supports-hyperlinks, supports-unicode, tempfile, time, tracing, tracing-chrome, tracing-subscriber, unicase, unicode-xid, url, varisat, walkdir, windows-sys warning: aborting upgrade due to dry run ❯ target/debug/cargo update --breaking --dry-run -Zunstable-options Updating crates.io index Upgrading itertools ^0.12.1 -> ^0.13.0 Upgrading pulldown-cmark ^0.10.3 -> ^0.11.0 Updating crates.io index Locking 3 packages to latest compatible versions Updating itertools v0.12.1 -> v0.13.0 Updating pulldown-cmark v0.10.3 -> v0.11.0 Updating pulldown-cmark-escape v0.10.0 -> v0.11.0 warning: not updating any files due to dry run ``` In both cases we see an upgrade of `itertools` to `^0.13.0` and `pulldown-cmark` to `^0.11.0`. The diff to the manifest (when it isn't a dry run) is as follows: ``` --- a/Cargo.toml +++ b/Cargo.toml `@@` -57,7 +57,7 `@@` humantime = "2.1.0" ignore = "0.4.22" im-rc = "15.1.0" indexmap = "2.2.6" -itertools = "0.12.1" +itertools = "0.13.0" jobserver = "0.1.31" lazycell = "1.3.0" libc = "0.2.154" `@@` -74,7 +74,7 `@@` pathdiff = "0.2.1" percent-encoding = "2.3.1" pkg-config = "0.3.30" proptest = "1.4.0" -pulldown-cmark = { version = "0.10.3", default-features = false, features = ["html"] } +pulldown-cmark = { version = "0.11.0", default-features = false, features = ["html"] } rand = "0.8.5" regex = "1.10.4" rusqlite = { version = "0.31.0", features = ["bundled"] } ``` # TODO - [x] In the case of `--incompatible`, we also need to let `update_lockfile` use `upgrades` in order to only update the incompatible dependencies. - [x] Testing all the different cases of package sources, version requirements, pinned versions, renamed dependencies, inherited workspace dependencies, multiple versions of the same dependency, selecting a subset `--package`, etc. - [x] Passing tests. - [x] Implement suggestions from reviews. - [x] The preservation of formatting in manifest files should be improved. - [x] Compare with `cargo upgrade`.

torhovland · 2024-06-11T08:23:11Z

I have started working on the --precise part of this issue too.

epage · 2024-06-11T18:30:43Z

Thanks!

I've added to the task list another test case we need (and to pin down the semantics of): cargo update --breaking only-compatible renamed non-semver-operator transitive-dep

torhovland · 2024-06-11T19:59:25Z

All right. We already cover only-compatible and renamed, though. Unless you mean they are important in that new, specific test case for some reason?

epage · 2024-06-11T20:17:50Z

We cover those for cargo update --breaking but I'm not seeing those covered for cargo update --breaking [SPEC]. We only test just-foo shared ws which are all candidates for upgrading. I'm concerned about the semantics of a user explicitly naming a package that --breaking doesn't apply to.

It might also be of interest to have a mixed workspace, where one package depends on renamed without a rename while another depends on it with a rename. This would need to be a separate test as this wouldn't error but the other case could potentially (depending on what semantics we want to give it)

torhovland · 2024-06-19T08:42:01Z

This bug will need a separate PR: #14049 (comment)

torhovland · 2024-06-24T10:18:29Z

More identified tasks

Handle dependencies that are both renamed/pinned and not in the same workspace. See More update --breaking tests #14049 (comment). Fixed in More update --breaking tests #14049.
Consider an error message if the command completed without doing any upgrades. See More update --breaking tests #14049 (comment). Improved in Add capability of making breaking changes in update --precise #14140. See A way for users to bulk upgrade across incompatible versions #12425 (comment). The breaking update will now have similar behaviour and output as the non-breaking update. The question still stands if the breaking update needs an explicit error message. See discussion below.
Consider if it is OK to not error when doing cargo update --breaking [email protected] (where [email protected] does not exist), but there is no lock file yet. This is consistent with the non-breaking update. See More update --breaking tests #14049 (comment).
semver_ext::matches_prerelease needs some improvement in order to support precise updates to prerelease versions. Fixed in Add capability of making breaking changes in update --precise #14140. See the new tests precise_prerelease and update_precise_breaking_pre_release_explicit_version_req.
Can we limit updates more in case of breaking upgrades? See Add capability of making breaking changes in update --precise #14140 (comment) and the test update_precise_breaking_shared_non_ws.
Improve an error message. See More update --breaking tests #14049 (comment).
Decide if we need both UPGRADING and UPDATING messages and if it is OK that the former outputs version requirements (^1.0) while the latter outputs versions (v1.0.0). See Add capability of making breaking changes in update --precise #14140 (comment).
Don't downgrade if pre-release was used — cargo update doesn't respect pre release #14178 (comment)

djc · 2024-06-24T11:04:07Z

Consider an error message if the command completed without doing any upgrades.

Not sure this makes sense to me? Does cargo update fail when there's nothing to update?

torhovland · 2024-06-24T11:24:35Z

The non-breaking update does not fail, but outputs something like this:

[UPDATING] `dummy-registry` index
[LOCKING] 0 packages to latest compatible versions
[NOTE] pass `--verbose` to see 3 unchanged dependencies behind latest

The breaking update currently only outputs this:

[UPDATING] `dummy-registry` index

So maybe the breaking one should add:

[UPGRADING] 0 packages to latest compatible versions

as well as a feature to list the other packages using --verbose?

torhovland · 2024-06-27T06:38:30Z

#14140 is making output consistent between breaking and non-breaking updates (both now use the same ops::update_lockfile()).

So a breaking update that ends up not upgrading anything will now output this:

[UPDATING] `[..]` index
[LOCKING] 0 packages to latest compatible versions
[NOTE] pass `--verbose` to see 3 unchanged dependencies behind latest

More `update --breaking` tests Related to #12425 (comment) in #12425.

m4rch3n1ng · 2024-06-27T18:39:39Z

would it be possible / is it currently planned to also update non-breaking versions in the Cargo.toml file?

cargo upgrade from cargo-edit currently supports that

name       old req compatible latest  new req
====       ======= ========== ======  =======
ratatui    0.26.1  0.26.1     0.27.0  0.27.0  // this is already supported in nightly
serde_json 1.0.117 1.0.118    1.0.118 1.0.118 // this is missing currently

i don't know if this is a desired feature, but since cargo upgrade already does it i am just wondering if this hasn't been discussed yet, has been discussed and has been decided against or has discussed and decided for, but just hasn't been implemented yet or if it is in another issue entirely?

epage · 2024-06-28T01:54:20Z

That is covered in #12425 (comment)

Somewhere between deferred and rejected (speaking for myself): Support in cargo update for writing to the manifest for non-breaking changes, like bulk compatible upgrades of version requirements (ie a -save flag) which was one of our lower priority workflows. A --save flag is more about updating versions for your dependents, which while important for having valid lower-bounds on version requirements, doesn't fit with the existing model of cargo update. Maybe in the future we can find a way to express this in cargo update that fits with how it works or maybe another command can take on this role. We just aren't wanting to distract our efforts for handling most of the use cases to handle this one

VorpalBlade · 2024-07-06T22:09:31Z

These are alternatives I had considered that help give an idea of what I mean by fitting into cargo.

cargo update always modifies Cargo.toml

This would be a breaking change

This would get in the way of people intentionally keeping separate versions from version requirements

For my use case of cargo upgrade (which cargo update --breaking has been advertised as a replacement of) this would be the mode I want. I'm fine with it being an optional flag to do so, but currently cargo update --breaking is a step back functionality wise (performance is of course better though).

Quoting myself from #14204 (apparently @epage prefers feedback in this issue instead):

I was led to believe that cargo +nightly -Zunstable-options update --breaking should be a drop-in replacement for cargo upgrade -i. But it isn't. Specifically it doesn't seem to upgrade Cargo.toml unless there is a breaking change.

I use cargo upgrade to upgrade to new minor versions in Cargo.toml too. There are several reasons for this:

As I'm on the latest version when developing, I can't be sure I'm not relying on some new API that didn't exist in the version that is declared in Cargo.toml. While I believe there is some "min-version" flag to test with, I prefer to just force everything the latest. (No I don't care about LTS distros like Debian etc, not one bit, nor about people who are not on the most recent stable Rust. My MSRV is N.)

If there are any security issues in a dependency I'd also prefer to force the latest version there too.

As such it seems I will probably have to port cargo-upgrade from cargo-edit to sparse registry myself at some point. When and if I have time. As cargo update --breaking just doesn't cut it for my use case.

epage added A-new-subcommand Area: new subcommand Command-update C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage. labels Aug 1, 2023

epage mentioned this issue Aug 1, 2023

Merge cargo-upgrade into cargo killercup/cargo-edit#685

Open

11 tasks

epage mentioned this issue Aug 1, 2023

fix(update): Tweak CLI behavior #12428

Merged

epage added the T-cargo Team: Cargo label Aug 8, 2023

rfcbot added proposed-final-comment-period An FCP proposal has started, but not yet signed off. disposition-merge FCP with intent to merge labels Aug 8, 2023

rfcbot added the final-comment-period FCP — a period for last comments before action is taken label Aug 14, 2023

rfcbot removed the proposed-final-comment-period An FCP proposal has started, but not yet signed off. label Aug 14, 2023

epage mentioned this issue Aug 23, 2023

fix(update): Clarify meaning of --aggressive as --recursive #12544

Merged

epage mentioned this issue Aug 23, 2023

fix(update): Make -p more convenient by being positional #12545

Merged

loynoir mentioned this issue Mar 25, 2024

Error: The repo at path ... is unusable due to having an invalid HEAD reference killercup/cargo-edit#879

Open

This was referenced May 23, 2024

cargo-upgrade verbose option broken #13959

Closed

cargo update should not highlight non-semver-compatible "(latest: v0.23.5)" for indirect dependencies #13908

Open

torhovland mentioned this issue May 29, 2024

Add cargo update --breaking #13979

Merged

6 tasks

epage mentioned this issue Jun 3, 2024

fix!: Remove --allow-prerelease killercup/cargo-edit#581

Merged

torhovland mentioned this issue Jun 12, 2024

More update --breaking tests #14049

Merged

torhovland mentioned this issue Jun 25, 2024

Add capability of making breaking changes in update --precise #14140

Open

bors added a commit that referenced this issue Jun 27, 2024

Auto merge of #14049 - tweag:issue-12425-more-tests, r=epage

2607661

More `update --breaking` tests Related to #12425 (comment) in #12425.

weihanglo mentioned this issue Jul 2, 2024

cargo update doesn't respect pre release #14178

Open

epage mentioned this issue Jul 6, 2024

cargo update --breaking doesn't work like cargo upgrade -i #14204

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

A way for users to bulk upgrade across incompatible versions #12425

A way for users to bulk upgrade across incompatible versions #12425

epage commented Aug 1, 2023 •

edited

Loading

epage commented Aug 1, 2023

epage commented Aug 1, 2023 •

edited

Loading

epage commented Aug 8, 2023

rfcbot commented Aug 8, 2023 •

edited by weihanglo

Loading

djc commented Aug 8, 2023

rfcbot commented Aug 14, 2023

weihanglo commented Aug 16, 2023

epage commented Aug 16, 2023

MoSal commented Aug 23, 2023

epage commented Aug 23, 2023

loynoir commented Mar 25, 2024

torhovland commented May 28, 2024

epage commented May 28, 2024

torhovland commented May 28, 2024

epage commented May 28, 2024

epage commented May 28, 2024

torhovland commented May 29, 2024

torhovland commented Jun 11, 2024

epage commented Jun 11, 2024

torhovland commented Jun 11, 2024

epage commented Jun 11, 2024

torhovland commented Jun 19, 2024

torhovland commented Jun 24, 2024 •

edited by weihanglo

Loading

djc commented Jun 24, 2024

torhovland commented Jun 24, 2024 •

edited

Loading

torhovland commented Jun 27, 2024

m4rch3n1ng commented Jun 27, 2024

epage commented Jun 28, 2024

VorpalBlade commented Jul 6, 2024

A way for users to bulk upgrade across incompatible versions #12425

A way for users to bulk upgrade across incompatible versions #12425

Comments

epage commented Aug 1, 2023 • edited Loading

Problem

Proposed Solution

Notes

epage commented Aug 1, 2023

Care Abouts

Context

Interjection

epage commented Aug 1, 2023 • edited Loading

Proposal: cargo update only changes version requirements as a side effect

Potential related cargo update improvements

Alternatives

Misc Notes

epage commented Aug 8, 2023

rfcbot commented Aug 8, 2023 • edited by weihanglo Loading

djc commented Aug 8, 2023

rfcbot commented Aug 14, 2023

weihanglo commented Aug 16, 2023

epage commented Aug 16, 2023

MoSal commented Aug 23, 2023

epage commented Aug 23, 2023

loynoir commented Mar 25, 2024

torhovland commented May 28, 2024

epage commented May 28, 2024

torhovland commented May 28, 2024

epage commented May 28, 2024

epage commented May 28, 2024

torhovland commented May 29, 2024

torhovland commented Jun 11, 2024

epage commented Jun 11, 2024

torhovland commented Jun 11, 2024

epage commented Jun 11, 2024

torhovland commented Jun 19, 2024

torhovland commented Jun 24, 2024 • edited by weihanglo Loading

More identified tasks

djc commented Jun 24, 2024

torhovland commented Jun 24, 2024 • edited Loading

torhovland commented Jun 27, 2024

m4rch3n1ng commented Jun 27, 2024

epage commented Jun 28, 2024

VorpalBlade commented Jul 6, 2024

epage commented Aug 1, 2023 •

edited

Loading

epage commented Aug 1, 2023 •

edited

Loading

Proposal: `cargo update` only changes version requirements as a side effect

Potential related `cargo update` improvements

rfcbot commented Aug 8, 2023 •

edited by weihanglo

Loading

torhovland commented Jun 24, 2024 •

edited by weihanglo

Loading

torhovland commented Jun 24, 2024 •

edited

Loading