cargo
cargo copied to clipboard
`cargo install A B C` only updates A if A, B, C are outdated
Problem
PRECONDITION
have several outdated crates installed via cargo install
STEPS TO REPRODUCE
- cargo install the outdated packages in order to update them:
cargo install cargo-bloat cargo-tarpaulin cargo-test-fuzz
EXPECTED BEHAVIOUR: cargo installs/updates all three packages
ACTUAL BEHAVIOUR cargo only (re)installs/upgrades the very first package. The second and third packages were not touched. However, cargo claimed that it "successfully installed" them as well :thinking:
To find out which packages needed updating I ran
at 22:52:49 ❯ cargo install-update -lag
Polling registry 'https://index.crates.io/'...............................................
Package Installed Latest Needs update
cargo-bloat v0.12.0 v0.12.1 Yes
cargo-tarpaulin v0.29.2 v0.30.0 Yes
cargo-test-fuzz v5.1.0 v5.2.0 Yes
treereduce-rust v0.2.2 v0.3.0 Yes
alacritty v0.13.2 v0.13.2 No
bandwhich v0.22.2 v0.22.2 No
I then tried to upgrade some manually but only the first package was updated
at 22:52:58 ❯ cargo install cargo-bloat cargo-tarpaulin cargo-test-fuzz
Updating crates.io index
Downloaded cargo-bloat v0.12.1
Downloaded 1 crate (19.3 KB) in 0.09s
Ignored package `cargo-tarpaulin v0.29.2` is already installed, use --force to override
Ignored package `cargo-test-fuzz v5.1.0` is already installed, use --force to override
Installing cargo-bloat v0.12.1
Updating crates.io index
Locking 20 packages to latest compatible versions
Adding fallible-iterator v0.2.0 (latest: v0.3.0)
Adding scroll v0.11.0 (latest: v0.12.0)
Compiling libc v0.2.154
Compiling regex-syntax v0.8.3
Compiling uuid v1.8.0
Compiling fallible-iterator v0.2.0
Compiling scroll v0.11.0
Compiling pico-args v0.5.0
Compiling binfarce v0.2.1
Compiling json v0.12.4
Compiling multimap v0.10.0
Compiling pdb v0.8.0
Compiling memmap2 v0.9.4
Compiling term_size v0.3.2
Compiling regex-automata v0.4.6
Compiling regex v1.10.4
Compiling cargo-bloat v0.12.1
Finished `release` profile [optimized] target(s) in 20.11s
Replacing /home/matthias/.cargo/bin/cargo-bloat
Replaced package `cargo-bloat v0.12.0` with `cargo-bloat v0.12.1` (executable `cargo-bloat`)
Summary Successfully installed cargo-tarpaulin, cargo-test-fuzz, cargo-bloat!
Steps
No response
Possible Solution(s)
No response
Notes
No response
Version
cargo 1.80.0-nightly (4de0094ac 2024-05-09)
release: 1.80.0-nightly
commit-hash: 4de0094ac78743d2c8ff682489e35c8a7cafe8e4
commit-date: 2024-05-09
host: x86_64-unknown-linux-gnu
libgit2: 1.7.2 (sys:0.18.3 vendored)
libcurl: 8.6.0-DEV (sys:0.4.72+curl-8.6.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w 11 Sep 2023
os: Manjaro 23.1.4 (Vulcan) [64-bit]
@rustbot label +Command-install
I don't find a text description in the cargo book that cargo install can install multiple binaries at the same time. I also don't see any support for installing multiple packages at the same time in the code. Maybe this is more of a new feature?
Path:
- support for installing multiple binaries at the same time;
- modify documentation and error alerts for wrong command line arguments?
I'm leaning more towards the first one.
Ran this snippet but unable to reproduce.
CARGO_HOME=myhome cargo +nightly install [email protected] [email protected] [email protected]
CARGO_HOME=myhome cargo +nightly install-update -lag
CARGO_HOME=myhome cargo +nightly install cargo-bloat cargo-tarpaulin cargo-test-fuzz
CARGO_HOME=myhome cargo +nightly install-update -lag
Have you configured CARGO_HOME, CARGO_TARGET_DIR, or any other settings that might affect the install root or something else?
@heisen-li. The feature is supported since https://github.com/rust-lang/cargo/pull/4216 (1.21). The cargo install man page also has ellipsis (…) on the CLI synopsis, indicating it accepts multiple crates. And there is a test case exercising it: https://github.com/rust-lang/cargo/blob/2f17770a15b5e6abe3348d4fcefc08b223e05968/tests/testsuite/install.rs#L217-L221
I don't think I have anything special set up, im using the default cargo home at ~/.cargo/
I think I ran the install command while cwd == /tmp/ but would be surprised if that makes a difference.
I can still reproduce this. Is there some kind of debugging I can enable to see why cargo decides not to upgrade a package perhaps?
Can you show the contents of ~/.cargo/crates2.json for these 3 entries?
And maybe post the output of cargo +nightly config get -Zunstable-options (remove any sensitive information like tokens).
FWIW I get this too with cargo install --locked bacon cbindgen cargo-audit cargo-insta cargo-llvm-cov cargo-release default-target mdbook mdbook-admonish mdbook-footnote mdbook-toc nextest wasm-bindgen-cli wasm-opt wasm-pack (from https://github.com/PRQL/prql/blob/caed477a1f1850695854fe43f95efff02dda021f/Taskfile.yml#L123).
But I also can't reproduce with the example above, so there's likely some moderating condition...