Bad interaction with cargo binstall : binstall claims a binary is installed, when it's not available

[HadrienG2]

Not sure if this should be fixed on the rust-cache or the cargo-binstall side, but it seems rust-cache caches enough for cargo-binstall to think that a binary is installed, but not enough for the binary to actually be available in ~/.cargo/bin, resulting in this sort of CI failure:

$ cargo binstall -y cargo-machete && cargo machete
 INFO resolve: Resolving package: 'cargo-machete'
 INFO resolve: cargo-machete v0.6.2 is already installed, use --force to override
 INFO Done in 182.512402ms
error: no such command: `machete`

    View all installed commands with `cargo --list`
    Find a package to install `machete` with `cargo search cargo-machete`

While this is being investigated, the obvious workaround is to run cargo binstall with the -f flag in CI jobs.

[gekh]

Same issue.

jobs:
  build:
    name: Deploy on test
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
      - name: Run sccache-cache
        uses: mozilla-actions/sccache-action@v0.0.5
        env:
          SCCACHE_GHA_ENABLED: "true"
          RUSTC_WRAPPER: "sccache"
      - name: Install binstall
        run: curl -L --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/cargo-bins/cargo-binstall/main/install-from-binstall-release.sh | bash
      - name: Install dx
        run: cargo binstall dioxus-cli -y
      - name: Build
        run: dx build --release

Fails with

Run dx build --release
/home/runner/work/_temp/4450bfb9-31d4-4702-8690-293d0399cbed.sh: line 1: dx: command not found
Error: Process completed with exit code 127.

[akesson]

From what I can see, the ~/.cargo/.crates.toml gets cached, but not the binaries that are installed in the ~/.cargo/bin directory. Which also means that cargo install --list happily shows a list of installed binaries that doesn't correspond to the what is available.