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
Separate error code for cargo install
failing due to binary already installed
#11513
Comments
Out of curiosity, which version are you using? IIRC from Rust 1.41, $ cargo install --list
cargo-expand v1.0.36:
cargo-expand
$ cargo install cargo-expand
Updating crates.io index
Ignored package `cargo-expand v1.0.36` is already installed, use --force to override
$ echo $?
0 |
This is on But I suspect then that there's a bad interaction with the |
I would recommend updating the cache action to include the |
@ehuss that documentation explicitly lists the things to cache and neither |
It is telling caching things to avoid redownload not rebuild executables. I guess that's the difference. Perhaps we can expand the paragraph with some sentenses about how to cache installed binaries. |
I think that would be beneficial yes. I've actually copied my own CI settings from another project so I'm not alone making that mistake. How can we determine the set of files which is necessary to cache for installed binaries? I don't even understand |
cargo/src/cargo/ops/common_for_install_and_uninstall.rs Lines 23 to 35 in 7fb01c6
It has been three years since the feature got stabilized. Maybe it's about time to remove v1 tracking file. |
For those interested in helping this, here is the place we need a new paragraph added. Could be something like “If binaries installed via cargo/src/doc/src/guide/cargo-home.md Lines 54 to 66 in a5d47a7
|
@rustbot claim |
Corrected documentation of how to cache binaries installed with `cargo install` in CI workflows Fix for #11513. Updated the cargo book documentation on how to cache the `$CARGO_HOME` directory in CI workflows (added that the `.crates.toml` and `.crates2.json` files must be cached alongside the `/bin` folder, if installed binaries are cached)
Close as #11592 added a tip to cache those two tracking files. Thank you everyone for participating the discussion :) |
Thanks for the fix! |
Properly cache `.crates.toml` and `.crates2.json` as recommended by the cargo team here: rust-lang/cargo#11513. This ensures installed cargo binaries are cached, and restored correctly. Remove the `--force` flag from the tarpaulin install, to use the cached version if available and speed up the coverage build.
Properly cache `.crates.toml` and `.crates2.json` as recommended by the cargo team here: rust-lang/cargo#11513. This ensures installed cargo binaries are cached, and restored correctly. Remove the `--force` flag from the tarpaulin install, to use the cached version if available and speed up the coverage build.
Just to circle back, I've finally updated the CI of my project and confirmed that even without the |
This should fix these errors: ``` error: binary `wasm-bindgen` already exists in destination binary `wasm-bindgen-test-runner` already exists in destination binary `wasm2es6js` already exists in destination ``` See rust-lang/cargo#11513.
Problem
I'm trying to use
cargo install
in CI on GitHub, to installcargo-tarpaulin
. Howevercargo install
might fail if the CI agent already has the version ofcargo-tarpaulin
that I need. Since it takes a bit to install, I also want to use GitHub caching, so want to avoid--force
. However, I still want to fail CI if the install fails for any other reason than "the version is already installed". Unfortunatelycargo
returns a single error code so there's no way for me to discriminate those two failures, and no easy way that I know of either to check if a binary is installed (cargo install --list
is hard to parse via script due to its nested listing which outputs both the package and its binaries, which are often the same).Proposed Solution
Have
cargo
return a different error code when not using--force
and the version of the binary is already installed.Notes
Briefly discussed on Discord here.
The text was updated successfully, but these errors were encountered: