db45f2fb7f
- Refactor: Mv fn `utils::asyncify` into mod `utils`
- Improve err msg for task failure in `utils::asyncify`
- Make sure `asyncify` always returns the same annoymous type
that implements `Future` if the `T` is same.
- Rewrite `extract_bin` to avoid `block_in_place`
support cancellation by dropping
- Rm unused dep scopeguard from binstalk-downloader
- Rewrite `extract_tar_based_stream` so that it is cancellable by dropping
- Unbox `extract_future` in `async_extracter::extract_zip`
- Refactor `Download` API: Remove `CancellationFuture` as param
since all futures returned by `Download::and_*` does not call
`block_in_place`, so they can be cancelled by drop instead of using this
cumbersome hack.
- Fix exports from mod `async_tar_visitor`
- Make `signal::{ignore_signals, wait_on_cancellation_signal}` private
- Rm the global variable `CANCELLED` in `wait_on_cancellation_signal`
and rm fn `wait_on_cancellation_signal_inner`
- Optimize `wait_on_cancellation_signal`: Avoid `tokio::select!` on `not(unix)`
- Rm unnecessary `tokio::select!` in `wait_on_cancellation_signal` on unix
Since `unix::wait_on_cancellation_signal_unix` already waits for ctrl + c signal.
- Optimize `extract_bin`: Send `Bytes` to blocking thread for zero-copy
- Optimize `extract_with_blocking_decoder`: Avoid dup monomorphization
- Box fut of `fetch_crate_cratesio` in `PackageInfo::resolve`
- Optimize `extract_zip_entry`: Spawn only one blocking task per fn call
by using a mspc queue for the data to be written to the `outfile`.
This would improve efficiency as using `tokio::fs::File` is expensive:
It spawns a new blocking task, which needs one heap allocation and then
pushed to a mpmc queue, and then wait for it to be done on every loop.
This also fix a race condition where the unix permission is set before
the whole file is written, which might be used by attackers.
- Optimize `extract_zip`: Use one `BytesMut` for entire extraction process
To avoid frequent allocation and deallocation.
- Optimize `extract_zip_entry`: Inc prob of reusing alloc in `BytesMut`
Performs the reserve before sending the buf over mpsc queue to
increase the possibility of reusing the previous allocation.
NOTE: `BytesMut` only reuses the previous allocation if it is the
only one holds the reference to it, which is either on the first
allocation or all the `Bytes` in the mpsc queue has been consumed,
written to the file and dropped.
Since reading from entry would have to wait for external file I/O,
this would give the blocking thread some time to flush `Bytes`
out.
- Disable unused feature fs of dep tokio
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
|
||
|---|---|---|
| .cargo | ||
| .github | ||
| crates | ||
| .editorconfig | ||
| .gitignore | ||
| Cargo.lock | ||
| Cargo.toml | ||
| README.md | ||
| SUPPORT.md | ||
Cargo B(inary)Install
cargo binstall provides a low-complexity mechanism for installing rust binaries as an alternative to building from source (via cargo install) or manually downloading packages. This is intended to work with existing CI artifacts and infrastructure, and with minimal overhead for package maintainers.
binstall works by fetching the crate information from crates.io, then searching the linked repository for matching releases and artifacts, with fallbacks to quickinstall and finally cargo install if these are not found.
To support binstall maintainers must add configuration values to Cargo.toml to allow the tool to locate the appropriate binary package for a given version and target. See SUPPORT.md for more detail.
Status
You probably want to see this page as it was when the latest version was published for accurate documentation.
Installation
To get started using cargo-binstall first install the binary (either via cargo install cargo-binstall or by downloading a pre-compiled release), then extract it using tar or unzip and move it into $HOME/.cargo/bin.
We recommend using the pre-compiled ones because we optimize those more than a standard source build does.
To upgrade, use cargo binstall cargo-binstall!
Usage
Supported packages can be installed using cargo binstall NAME where NAME is the crates.io package name.
Package versions and targets may be specified using the --version and --target arguments respectively, and will be installed into $HOME/.cargo/bin by default. For additional options please see cargo binstall --help.
[garry] ➜ ~ cargo binstall radio-sx128x --version 0.14.1-alpha.5
21:14:15 [INFO] Resolving package: 'radio-sx128x'
21:14:18 [INFO] This will install the following binaries:
21:14:18 [INFO] - sx128x-util (sx128x-util-x86_64-apple-darwin -> /Users/ryankurte/.cargo/bin/sx128x-util-v0.14.1-alpha.5)
21:14:18 [INFO] And create (or update) the following symlinks:
21:14:18 [INFO] - sx128x-util (/Users/ryankurte/.cargo/bin/sx128x-util-v0.14.1-alpha.5 -> /Users/ryankurte/.cargo/bin/sx128x-util)
21:14:18 [INFO] Do you wish to continue? yes/[no]
? yes
21:14:20 [INFO] Installing binaries...
21:14:21 [INFO] Done in 6.212736s
Unsupported crates
Nowadays, cargo-binstall is smart enough. All you need just passing the crate name.
cargo binstall --no-confirm --no-symlinks cargo-edit cargo-watch cargo-tarpaulin \
watchexec-cli cargo-outdated just fnm broot stylua
If your favorite package fails to install, you may specify the Cargo.toml metadata entries for pkg-url, bin-dir, and pkg-fmt at the command line, with values as documented below.
For example:
$ binstall \
--pkg-url="{ repo }/releases/download/{ version }/{ name }-{ version }-{ target }.{ archive-format }" \
--pkg-fmt="txz" crate_name
Upgrade installed crates
The most ergonomic way to upgrade the installed crates is with cargo-update. cargo-update automatically uses cargo-binstall to install the updates if cargo-binstall is present.
Supported crates such as cargo-binstall itself can also be updated with cargo-binstall as in the example in Installation above.
FAQ
- Why use this?
- Because
wget-ing releases is frustrating,cargo installtakes a not inconsequential portion of forever on constrained devices, and often putting together actual packages is overkill.
- Because
- Why use the cargo manifest?
- Crates already have these, and they already contain a significant portion of the required information.
Also, there's this great and woefully underused (IMO)
[package.metadata]field.
- Crates already have these, and they already contain a significant portion of the required information.
Also, there's this great and woefully underused (IMO)
- Is this secure?
- Yes and also no? We're not (yet? #1) doing anything to verify the CI binaries are produced by the right person/organization.
However, we're pulling data from crates.io and the cargo manifest, both of which are already trusted entities, and this is
functionally a replacement for
curl ... | bashorwget-ing the same files, so, things can be improved but it's also fairly moot
- Yes and also no? We're not (yet? #1) doing anything to verify the CI binaries are produced by the right person/organization.
However, we're pulling data from crates.io and the cargo manifest, both of which are already trusted entities, and this is
functionally a replacement for
- What do the error codes mean?
- You can find a full description of errors including exit codes here: https://docs.rs/binstalk/latest/binstalk/errors/enum.BinstallError.html
- Can I use it in CI?
- Yes! For GitHub Actions, we recommend the excellent taiki-e/install-action, which has explicit support for selected tools and uses
cargo-binstallfor everything else.
- Yes! For GitHub Actions, we recommend the excellent taiki-e/install-action, which has explicit support for selected tools and uses
If you have ideas/contributions or anything is not working the way you expect (in which case, please include an output with --log-level debug) and feel free to open an issue or PR.