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
A way for users to bulk upgrade across incompatible versions #12425
Comments
Below is some background on what we are using to help come up with a design Care AboutsPriorities
Primary use cases:
Secondary use cases are:
Some open questions we had
ContextCurrently,
Version requirement editing is different in that
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: Some design tools we can consider include
InterjectionThrough 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
I also realized that my Windows Updates vs Windows Upgrades analogy for |
Proposal:
|
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.
This proposal has been up here and on internals for a bit now without any major concerns raised. @rfcbot fcp merge |
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. |
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! |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
Can |
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.
This is probably stating the obvious. But if a dependency is imprecise, current Let's say a dependency is 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 |
FYI on zulip I brought up the idea of a |
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.
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.
Prepare for partial-version package specs ### What does this PR try to resolve? These are refactorings, test expansions, and cleanups I saw as I was preparing to implement support for `foo@0.1` as proposed in #12425. I figured these changes stand on their own so I separated them out. One further change I considered was that `foo@0` will suggest `foo` in a "did you mean" message. This is a big off *but* most likely any fix for this would be undone by the work to support `foo@0.1`, so I held off on it. ### How should we test and review this PR? Each change is broken down into an individual commit
This was proposed in rust-lang#12425 to help improve usability of the existing `cargo update` when dealing with the added workflows.
This was proposed in rust-lang#12425 to help improve usability of the existing `cargo update` when dealing with the added workflows.
This was proposed in rust-lang#12425 to help improve usability of the existing `cargo update` when dealing with the added workflows.
This was proposed in rust-lang#12425 to help improve usability of the existing `cargo update` when dealing with the added workflows.
This was proposed in rust-lang#12425 to help improve usability of the existing `cargo update` when dealing with the added workflows.
This was proposed in rust-lang#12425 to help improve usability of the existing `cargo update` when dealing with the added workflows.
This was proposed in rust-lang#12425 to help improve usability of the existing `cargo update` when dealing with the added workflows.
This was proposed in rust-lang#12425 to help improve usability of the existing `cargo update` when dealing with the added workflows.
This was proposed in rust-lang#12425 to help improve usability of the existing `cargo update` when dealing with the added workflows.
This was proposed in rust-lang#12425 to help improve usability of the existing `cargo update` when dealing with the added workflows.
feat(pkgid): Allow incomplete versions when unambigious ### What does this PR try to resolve? This was proposed in #12425 to help sand off some of the rough edges around `cargo update` for its wider use it would be getting. Its easy to accidentally get duplicate copies packages in a repo and a pain to have to specify the full version when `cargo update -p foo@1` is sufficient to describe it. Other effects - profile overrides also supports this since we already allow a spec to match multiple items - `cargo clean -p foo@...` already ignored the version, so now we also parse and ignore the partial version - `cargo tree --prune` will now accept partial versions and will match all of them Parts not effected: - Replacements - Two of the cases were found and we treat it as if the version isn't present which will error, so I think that is correct ### How should we test and review this PR? This extracts `PartialVersion` from `RustVersion` where `RustVersion` is a more specialized variant, not allowing prerelease or build. This works by adopting `PartialVersion` into `PackageIdSpec`. For `PackageIdSpec::query`, this will "just work". ### Additional information
This was proposed in rust-lang#12425 to help improve usability of the existing `cargo update` when dealing with the added workflows.
feat(pkgid): Allow incomplete versions when unambigious ### What does this PR try to resolve? This was proposed in #12425 to help sand off some of the rough edges around `cargo update` for its wider use it would be getting. Its easy to accidentally get duplicate copies packages in a repo and a pain to have to specify the full version when `cargo update -p foo@1` is sufficient to describe it. Other effects - profile overrides also supports this since we already allow a spec to match multiple items - `cargo clean -p foo@...` already ignored the version, so now we also parse and ignore the partial version - `cargo tree --prune` will now accept partial versions and will match all of them Parts not effected: - Replacements - Two of the cases were found and we treat it as if the version isn't present which will error, so I think that is correct ### How should we test and review this PR? This extracts `PartialVersion` from `RustVersion` where `RustVersion` is a more specialized variant, not allowing prerelease or build. This works by adopting `PartialVersion` into `PackageIdSpec`. For `PackageIdSpec::query`, this will "just work". ### Additional information
feat(update): Tell users when they are still behind ### What does this PR try to resolve? Part of this is an offshoot of #12425 which is about pulling some of `cargo upgrade`s behavior into `cargo update`. One of the "'Potential related `cargo update` improvements" is informing the user when they are behind. Part of this is to help close the gap of users being behind on their dependencies unaware. This is commonly raised when discussing an MSRV-aware resolver (see rust-lang/rfcs#3537) but breaking changes are just as big of a deal so I'm starting this now. See also #7167, #4309 Compared to `cargo upgrade` / `cargo outdated`, I'm taking a fairly conservative approach and tweaking the existing output as a starting point / MVP. We can experiment with a richer or easier-to-consume way of expressing this over time. I view us telling people they aren't on the latest as a warning, so I made that text yellow. `clap $ cargo update --dry-run` ![image](https://github.com/rust-lang/cargo/assets/60961/4bf151e3-6b57-4073-8822-9140dd731d5e) `clap $ cargo update --dry-run --verbose` ![image](https://github.com/rust-lang/cargo/assets/60961/fbf802fb-3a6a-4e8b-a6ec-4ce49fb505f6) ### How should we test and review this PR? This sets up the minimal implementation and slowly adds bits at a time, with a test first that demonstrates it. ### Additional information I'm expecting that the `cargo upgrade` integration will extend the notes to say something like "X dependencies may be updated with `--breaking`"
Really hope yarn is one of the nodejs package managers, and it supports yarn 1 https://classic.yarnpkg.com/lang/en/docs/cli/upgrade-interactive/ yarn 4 https://yarnpkg.com/cli/upgrade-interactive Not similar to 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 -------- |
Problem
A lot of incompatible upgrades have a small enough of breakages that a "upgrade all of my incompatible version requirements" would make it easier to go through this process.
This is currently exposed in the
cargo upgrade
commandProposed Solution
See https://internals.rust-lang.org/t/feedback-on-cargo-upgrade-to-prepare-it-for-merging/17101/141
Notes
No response
The text was updated successfully, but these errors were encountered: