A simple way to update all `cargo install`ed binaries (potential `cargo-install-update` integration)

[eddyp]

Describe the problem you are trying to solve

As suggested in the second comment of #2082, it would be really useful to be able to easily upgrade all binary tools installed via cargo install in a system, now that #2082 was fixed for a single package (proposal in #6667 and implementation from #6798 stabilization via #7560).

Describe the solution you'd like

We currently have cargo install --list list information about the tools, but cargo appears to be lacking a way to upgrade them en-masse like this:

For instance, on a system I see there are some tools I have, but it's not clear if they are up to date:

C:\>cargo install --list
cargo-add v0.2.0:
    cargo-add.exe
cargo-asm v0.1.16:
    cargo-asm.exe
    cargo-llvm-ir.exe
cargo-audit v0.11.2:
    cargo-audit.exe
cargo-binutils v0.1.6:
    cargo-nm.exe
    cargo-objcopy.exe
    cargo-objdump.exe
    cargo-profdata.exe
    cargo-readobj.exe
    cargo-size.exe
    cargo-strip.exe
cargo-bloat v0.9.3:
    cargo-bloat.exe
cargo-deny v0.6.6:
    cargo-deny.exe
....

And the way I was thinking it would have worked was something like this (NOT AN ACTUAL LISTING):

C:\>cargo install --update-all
cargo-add v0.2.0: up to date
cargo-asm v0.1.16: up to date
cargo-audit v0.11.2: outdated, installing v0.14.1
cargo-binutils v0.1.6: outdated, instaling v0.3.3
cargo-bloat v0.9.3: outdated, installing v0.10.0
cargo-deny v0.6.6: outdated, installing v0.9.1
...

The --update-all option can have a pretend/dry-run suboption that coud just list what would be done, or whatever that flag name might be named in other places in cargo (suggestions for flag name, shamelessly copied from apt: -s, --simulate, --just-print, --dry-run, --recon, --no-act).

It might be cargo install --list could be complemented by a flag that could list the cargo.io versions, too, but since that would hit the internet for info, that probably makes sense not to be default. Not sure what's best, as cargo onstall --list feels like the proper place to see the info (including the 'is this up to date' info).

Notes

Not sure what should happen WRT semantic versioning, but my gut feeling under-0 versions could be updated by default, but the 1.0+ versions might make sense to have the behavior follow SemVer and not upgrade, so not sure which is a sane default.

[weihanglo]

There exists a cargo-update crate. Does it fit this use case?

[weihanglo]

For the SemVer compatibility cargo/crates.io repecting to, The Cargo Book gets a nice chapter, and it seems that under 0.y.x any y change is considered as major release.

This guide uses the terms "major" and "minor" assuming this relates to a "1.0.0" release or later. Initial development releases starting with "0.y.z" can treat changes in "y" as a major release, and "z" as a minor release. "0.0.z" releases are always major changes. This is because Cargo uses the convention that only changes in the left-most non-zero component are considered incompatible.

[eddyp]

There exists a cargo-update crate. Does it fit this use case?

Looking at the crate page look like the functionality is the desired one:

C:\>cargo install-update -l
    Updating registry 'https://github.com/rust-lang/crates.io-index'

Package           Installed  Latest   Needs update
cargo-audit       v0.11.2    v0.14.1  Yes
cargo-binutils    v0.1.6     v0.3.3   Yes
cargo-inspect     v0.7.0     v0.10.3  Yes
cargo-llvm-lines  v0.4.6     v0.4.11  Yes
cargo-outdated    v0.9.9     v0.9.15  Yes
cargo-pants       v0.1.1     v0.1.25  Yes
...
cargo-deps        v1.4.1     v1.4.1   No
cargo-update      v7.0.1     v7.0.1   No
ripgrep           v12.1.1    v12.1.1  No

With its cargo install-update-config command seems to also handle the configuration of packages part that was mentioned in https://github.com/rust-lang/cargo/issues/2082#issuecomment-851346910 :

C:\>cargo install-update -h
cargo-install-update.exe-install-update 7.0.1
наб <[email protected]>
Yann Simon <[email protected]>
ven <[email protected]>
Cat Plus Plus <[email protected]>
Liigo <[email protected]>
azyobuzin <[email protected]>
Tatsuyuki Ishi <[email protected]>
Tom Prince <[email protected]>
Mateusz Mikuła <[email protected]>
sinkuu <[email protected]>
Alex Burka <[email protected]>
Matthias Krüger <[email protected]>
Daniel Holbert <[email protected]>
Jonas Bushart <[email protected]>
Harrison Metzger <[email protected]>
Benjamin Bannier <[email protected]>
Dimitris Apostolou <[email protected]>
Corbin Uselton <[email protected]>
QuarticCat <[email protected]>
A cargo subcommand for checking and applying updates to installed executables -- configuration

USAGE:
    cargo-install-update-config.exe install-update-config [FLAGS] [OPTIONS] <PACKAGE>

FLAGS:
    -a, --any-version               Allow any version
        --debug                     Compile the package in debug mode
        --enforce-lock              Require Cargo.lock to be up to date
    -h, --help                      Prints help information
        --install-prereleases       Install prerelease versions
        --no-enforce-lock           Don't enforce Cargo.lock
        --no-install-prereleases    Filter out prerelease versions
        --no-respect-binaries       Install all binaries
        --release                   Compile the package in release mode
        --respect-binaries          Only install already installed binaries

OPTIONS:
    -c, --cargo-dir <CARGO_DIR>                  The cargo home directory. Default: $CARGO_HOME or $HOME/.cargo
    -d, --default-features <DEFAULT_FEATURES>    Whether to allow default features
    -f, --feature <FEATURE>...                   Feature to enable
    -n, --no-feature <DISABLED_FEATURE>...       Feature to disable
    -t, --toolchain <TOOLCHAIN>                  Toolchain to use or empty for default
    -v, --version <VERSION_REQ>                  Require a cargo-compatible version range

ARGS:
    <PACKAGE>    Package to configure

and it seems cargo install-update --all does its job:

C:\>cargo install-update --all
    Updating registry 'https://github.com/rust-lang/crates.io-index'

Package           Installed  Latest   Needs update
cargo-audit       v0.11.2    v0.14.1  Yes
cargo-binutils    v0.1.6     v0.3.3   Yes
cargo-inspect     v0.7.0     v0.10.3  Yes
cargo-llvm-lines  v0.4.6     v0.4.11  Yes
cargo-outdated    v0.9.9     v0.9.15  Yes
cargo-pants       v0.1.1     v0.1.25  Yes
cargo-udeps       v0.1.1     v0.1.21  Yes
git-absorb        v0.6.0     v0.6.6   Yes
git-bonsai        v0.1.0     v0.2.1   Yes
git-trim          v0.3.2     v0.4.2   Yes
hexyl             v0.5.1     v0.8.0   Yes
sd                v0.6.5     v0.7.6   Yes
svd2rust          v0.17.0    v0.19.0  Yes
tokei             v10.0.1    v12.1.2  Yes
topgrade          v5.8.1     v6.9.1   Yes
xargo             v0.3.22    v0.3.23  Yes
cargo-add         v0.2.0     v0.2.0   No
cargo-asm         v0.1.16    v0.1.16  No
cargo-bloat       v0.10.0    v0.10.0  No
cargo-deny        v0.9.1     v0.9.1   No
cargo-deps        v1.4.1     v1.4.1   No
cargo-update      v7.0.1     v7.0.1   No
ripgrep           v12.1.1    v12.1.1  No

Updating cargo-audit
  Downloaded cargo-audit v0.14.1
  Downloaded 1 crate (157.5 KB) in 1.16s
    Updating crates.io index
  Installing cargo-audit v0.14.1
  Downloaded addr2line v0.15.2
  Downloaded once_cell v1.7.2
  Downloaded stable_deref_trait v1.2.0
  Downloaded generational-arena v0.2.8
  Downloaded backtrace v0.3.60
  Downloaded object v0.25.2
  Downloaded tracing-core v0.1.18
  Downloaded unicode-normalization v0.1.19
  Downloaded zeroize v1.3.0
  Downloaded regex-automata v0.1.10
....

Just as a matter of taste, I kind of dislike the command names and the fact it prints the details of the authors upfront in -h invocations, but an integration into cargo proper could fix those.

The only reservation I have is the dependency on Cmake which might be a turnoff for some people, so it might make sense to integrate into cargo and drop the dependency:

Firstly, ensure you have CMake and the Required Libraries™.

Then proceed as usual:

    cargo install cargo-update

(Just as a coincidence I had Cmake installed on the system I tested, but I doubt I would have went through the trouble to install it if I didn't. It feels like this should be a native functionality of Cargo and I suspect much of the logic in cargo-update is already existing in cargo, including some corner cases, but that is just a hunch.)

[Logarithmus]

@weihanglo what about integrating https://lib.rs/cargo-update into cargo itself?

[weihanglo]

I am not a member cargo team, so the followings are only my 2 cents.

As Rust getting popular, the small cargo team cannot handle all these feature requests and bugs. They might not have extra time to take care more new commands. They need helps. If we do want to integrate cargo-update as a built-in command, there are things we can do:

• Learn how to organize and integrate a command into cargo, such as cargo-tree (integrated).
• Learn the possible obstacles we'll encounter during the integration, such as cargo-edit (ongoing).
• Learn what does the maintenance look like after integrating a new command, such as cargo-vendor (integrated).
• Discuss here or on Zulip #t-cargo about the design and idea of adding cargo-update. Also need to confirm whether or not an RFC is necessary.
• It will be pleasant if we can help maintain the new command for a reasonable period after the integration.

Looking forward to making cargo more friendly together!

[martin-braun]

This is a work-around which doesn't require cargo-update:

cargo install $(cargo install --list | egrep '^[a-z0-9_-]+ v[0-9.]+:$' | cut -f1 -d' ')

[Rudxain]

This

I'm afraid the Cargo CLI API may not be stable enough to guarantee the regex doesn't break. I understand it's just a workaround, so that should be expected