Closed 0atman closed 1 year ago
Is there a sleep(1) in there somewhere? 😅
Actually yes, you found out the cause faster than I do.
Our crates.io client has a one request per each second rate limit, I think it was copied from crates_io_api.
We could remove that and just the global rate limit policy.
@0atman We have released cargo-binstall v1.3.0 which should fixed this by switching to sparse index and use the global rate-limit instead. Please have a try and I'd like your feedback!
If you, like me, maintain a large list of system tools in Rust and re-run the install line now and then to keep up to date, you'll notice a very long delay checking each crate for being up to date, even if no version bump has happened.
After package indexing, which is very fast, this process is entirely local and so shouldn't be slow. Yet it is, about 1s delayed per item.
Here's my preposterous install line that I will take no notes on:
Output immediately jumps to here, then spins 1s for each of the following lines:
Is there a
sleep(1)
in there somewhere? :sweat_smile: