Skip to content
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 simple way to update all cargo installed binaries (potential cargo-install-update integration) #9527

Open
eddyp opened this issue May 31, 2021 · 10 comments
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-install E-medium Experience: Medium S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

Comments

@eddyp
Copy link

eddyp commented May 31, 2021

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.

@eddyp eddyp added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label May 31, 2021
@weihanglo
Copy link
Member

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

@weihanglo
Copy link
Member

weihanglo commented Jun 3, 2021

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
Copy link
Author

eddyp commented Jun 7, 2021

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 #2082 (comment) :

C:\>cargo install-update -h
cargo-install-update.exe-install-update 7.0.1
наб <nabijaczleweli@nabijaczleweli.xyz>
Yann Simon <yann.simon.fr@gmail.com>
ven <vendethiel@hotmail.fr>
Cat Plus Plus <piotrlegnica@piotrl.pl>
Liigo <liigo@qq.com>
azyobuzin <azyobuzin@users.sourceforge.jp>
Tatsuyuki Ishi <ishitatsuyuki@gmail.com>
Tom Prince <tom.prince@twistedmatrix.com>
Mateusz Mikuła <mati865@gmail.com>
sinkuu <sinkuupump@gmail.com>
Alex Burka <aburka@seas.upenn.edu>
Matthias Krüger <matthias.krueger@famsik.de>
Daniel Holbert <dholbert@cs.stanford.edu>
Jonas Bushart <jonas@bushart.org>
Harrison Metzger <harrisonmetz@gmail.com>
Benjamin Bannier <bbannier@gmail.com>
Dimitris Apostolou <dimitris.apostolou@icloud.com>
Corbin Uselton <corbinu@decimal.io>
QuarticCat <QuarticCat@protonmail.com>
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
Copy link

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

@weihanglo
Copy link
Member

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
Copy link

martin-braun commented Mar 15, 2023

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' ')

@weihanglo weihanglo added S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. E-medium Experience: Medium labels May 24, 2023
@weihanglo weihanglo changed the title Add cargo install --update-all as a simple way to update all locally installed tools with cargo install A simple way to update all cargo installed binaries (potential cargo-install-update integration) May 24, 2023
Rudxain added a commit to Rudxain/dotfiles that referenced this issue May 12, 2024
@Rudxain
Copy link

Rudxain commented May 12, 2024

This

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

@TaQuanMinhLong
Copy link

If you use nushell simply use this script

cargo install --list
    | parse "{package} v{version}:"
    | get package
    | each {|p| cargo install $p}

@jokeyrhyme
Copy link

cargo install --list --json would be amazing

@luccahuguet
Copy link

luccahuguet commented Oct 19, 2024

If you use nushell simply use this script

cargo install --list
| parse "{package} v{version}:"
| get package
| each {|p| cargo install $p}

@TaQuanMinhLong some crates only work with the locked option, so it might me better to go with

 cargo install --list
     | parse "{package} v{version}:"
     | get package
     | each {|p| cargo install $p --locked}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` Command-install E-medium Experience: Medium S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Projects
None yet
Development

No branches or pull requests

9 participants