actions/cargo-binstall
1
0
Fork 0
mirror of https://github.com/cargo-bins/cargo-binstall.git synced 2025-04-24 14:28:42 +00:00
Code Issues Projects Releases Packages Wiki Activity

Add support for Txz archives

Browse source
This commit is contained in:
Félix Saparelli 2021-03-06 22:35:05 +13:00
parent e5705171a7
commit 9c06ca94cb
No known key found for this signature in database
GPG key ID: B948C4BAE44FC474
5 changed files with 43 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

7
README.md
View file

@ -39,6 +39,7 @@ yes
- [ ] Unofficial packaging
- Package formats
- [x] Tgz
- [x] Txz
- [x] Tar
- [x] Bin
- Extraction / Transformation
@ -51,7 +52,7 @@ yes
## Supporting Binary Installation
`binstall` works with existing CI-built binary outputs, with configuration via `[package.metadata.binstall]` keys in the relevant crate manifest.
`binstall` works with existing CI-built binary outputs, with configuration via `[package.metadata.binstall]` keys in the relevant crate manifest.
When configuring `binstall` you can test against a local manifest with `--manifest-path=PATH` argument to use the crate and manifest at the provided `PATH`, skipping crate discovery and download.
To get started, add a `[package.metadata.binstall]` section to your `Cargo.toml. As an example, the default configuration would be:
@ -102,7 +103,7 @@ For example, the default configuration (as shown above) for a crate called `radi
- Installed to`$HOME/.cargo/bin/rust-radio-sx128x-v0.14.1-alpha.5`
- With a symlink from `$HOME/.cargo/bin/rust-radio-sx128x`
#### If the package name does not match the crate name
#### If the package name does not match the crate name
As is common with libraries / utilities (and the `radio-sx128x` example), this can be overridden by specifying the `pkg-url`:
@ -131,7 +132,7 @@ Which provides a binary path of: `sx128x-util-x86_64-unknown-linux-gnu[.exe]`. I
- Because `wget`-ing releases is frustrating, `cargo install` takes a not inconsequential portion of forever on constrained devices,
and often putting together actual _packages_ is overkill.
- Why use the cargo manifest?
- Crates already have these, and they already contain a significant portion of the required information.
- 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.
- Why not use a binary repository instead?
- Then we'd need to _host_ a binary repository, and worry about publishing and all the other fun things that come with releasing software.