search

cargo-bins / cargo-binstall

Binary installation for rust projects
GNU General Public License v3.0
1.63k stars 60 forks source link

min version requires rust 1.79 #1913

Open gilescope opened 2 months ago

gilescope commented 2 months ago

At the moment:

curl -L --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/cargo-bins/cargo-binstall/main/install-from-binstall-release.sh | bash

Gets the latest version which requires 1.79. We are stuck on 1.78 due to a rustc bug ( https://github.com/rust-lang/rust/issues/127351 ). In general it's probably good for a project like this to not require the latest rustc as it's widely used.

NobodyXu commented 2 months ago

I don't think we have a hard dependency on rust/cargo at runtime?

detect-targets does try using rustc to get current target, but it can fallback to other detection methods if rustc is not found.

gilescope commented 2 months ago

I get:

 Downloaded cargo-binstall v1.7.0
               +prep *failed* | error: cannot install package `cargo-binstall 1.7.0`, it requires rustc 1.79.0 or newer, while the currently active rustc version is 1.78.0

1.6.9 is fine but above that I get that error. Not too sure what's changed.

gilescope commented 2 months ago

Maybe there's a dependency that's had a patch that then pulls in the requirement? That would explain why it hit many versions at once. binstalk seems the only dep that changed between those versions

NobodyXu commented 2 months ago

If you run 

curl -L --proto '=https' --tlsv1.2 -sSf https://raw.githubusercontent.com/cargo-bins/cargo-binstall/main/install-from-binstall-release.sh | bash

It should use pre-built binaries.

BTW latest release is 1.10.4

TomAFrench commented 2 months ago

We ran into this earlier today as well (failing CI run https://github.com/AztecProtocol/aztec-packages/actions/runs/10810494413/attempts/2?pr=8434) we'd get a 403 error and then the script posted above fell back to attempt compilation from source.

Things have been fine since then so this was likely something that only occurs around the time a release is published although I would expect any issue like that (binaries not having been uploaded yet, etc.) would result in a 404 rather than a 403.

NobodyXu commented 2 months ago

I think you might hit the github API rate limit.

To fix it, you can pass GITHUB_TOKEN: ${ secrets.GITHUB_TOKEN } as env to cargo-binstall.

You can reduce the permissions of secrets.GITHUB_TOKEN using https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#permissions

NobodyXu commented 2 months ago

I think we should add this to FAQ for anyone