cargo-bins/cargo-binstall

Binary installation for rust projects

Cargo B(inary)Install

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 and searching the linked repository for matching releases and artifacts, falling back to the quickinstall third-party artifact host, to alternate targets as supported, and finally to cargo install as a last resort.

You may want to see this page as it was when the latest version was published.

Usage

$ cargo binstall [email protected]
 INFO resolve: Resolving package: 'radio-sx128x@=0.14.1-alpha.5'
 WARN The package radio-sx128x v0.14.1-alpha.5 (x86_64-unknown-linux-gnu) has been downloaded from github.com
 INFO This will install the following binaries:
 INFO   - sx128x-util (sx128x-util-x86_64-unknown-linux-gnu -> /home/.cargo/bin/sx128x-util)
Do you wish to continue? yes/[no]
? yes
 INFO Installing binaries...
 INFO Done in 2.838798298s

Binstall aims to be a drop-in replacement for cargo install in many cases, and supports similar options.

For unattended use (e.g. in CI), use the --no-confirm flag. For additional options please see cargo binstall --help.

Installation

If you already have it

To upgrade cargo-binstall, use cargo binstall cargo-binstall!

Quickly

Here are one-liners for downloading and installing a pre-compiled cargo-binstall binary.

Linux and macOS

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

Windows

Set-ExecutionPolicy Unrestricted -Scope Process; iex (iwr "https://raw.githubusercontent.com/cargo-bins/cargo-binstall/main/install-from-binstall-release.ps1").Content

Manually

Download the relevant package for your system below, unpack it, and move the cargo-binstall executable into $HOME/.cargo/bin:

OS	Arch	URL
Linux	x86_64	https://github.com/cargo-bins/cargo-binstall/releases/latest/download/cargo-binstall-x86_64-unknown-linux-musl.tgz
Linux	armv7	https://github.com/cargo-bins/cargo-binstall/releases/latest/download/cargo-binstall-armv7-unknown-linux-musleabihf.tgz
Linux	arm64	https://github.com/cargo-bins/cargo-binstall/releases/latest/download/cargo-binstall-aarch64-unknown-linux-musl.tgz
Mac	Intel	https://github.com/cargo-bins/cargo-binstall/releases/latest/download/cargo-binstall-x86_64-apple-darwin.zip
Mac	Apple Silicon	https://github.com/cargo-bins/cargo-binstall/releases/latest/download/cargo-binstall-aarch64-apple-darwin.zip
Mac	Universal (both archs)	https://github.com/cargo-bins/cargo-binstall/releases/latest/download/cargo-binstall-universal-apple-darwin.zip
Windows	Intel/AMD	https://github.com/cargo-bins/cargo-binstall/releases/latest/download/cargo-binstall-x86_64-pc-windows-msvc.zip
Windows	ARM 64	https://github.com/cargo-bins/cargo-binstall/releases/latest/download/cargo-binstall-aarch64-pc-windows-msvc.zip

From source

With a recent Rust installed:

cargo install cargo-binstall

In GitHub Actions

We provide a first-party, minimal action that installs the latest version of Binstall:

  - uses: cargo-bins/cargo-binstall@main

For more features, we recommend the excellent taiki-e/install-action, which has dedicated support for selected tools and uses Binstall for everything else.

Companion tools

These are useful third-party tools which work well with Binstall.

cargo-update

While you can upgrade crates explicitly by running cargo binstall again, cargo-update takes care of updating all tools as needed. It automatically uses Binstall to install the updates if it is present.

cargo-run-bin

Binstall and cargo install both install tools globally by default, which is fine for system-wide tools. When installing tooling for a project, however, you may prefer to both scope the tools to that project and control their versions in code. That's where cargo-run-bin comes in, with a dedicated section in your Cargo.toml and a short cargo subcommand. When Binstall is available, it installs from binary whenever possible... and you can even manage Binstall itself with cargo-run-bin!

Unsupported crates

Binstall is generally smart enough to auto-detect artifacts in most situations. However, if a package fails to install, you can manually specify the pkg-url, bin-dir, and pkg-fmt as needed at the command line, with values as documented in SUPPORT.md.

$ cargo-binstall \
  --pkg-url="{ repo }/releases/download/{ version }/{ name }-{ version }-{ target }.{ archive-format }" \
  --pkg-fmt="txz" \
  crate_name

Maintainers wanting to make their users' life easier can add explicit Binstall metadata to Cargo.toml to locate the appropriate binary package for a given version and target.

Signatures

We have initial, limited support for maintainers to specify a signing public key and where to find package signatures. With this enabled, Binstall will download and verify signatures for that package.

You can use --only-signed to refuse to install packages if they're not signed.

If you like to live dangerously (please don't use this outside testing), you can use --skip-signatures to disable checking or even downloading signatures at all.

FAQ

Why use this?

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. Also, there's this great and woefully underused (IMO) [package.metadata] field.

Is this secure?

Yes and also no?

We have initial support for verifying signatures, but not a lot of the ecosystem produces signatures at the moment. See #1 to discuss more on this.

We always pull the metadata from crates.io over HTTPS, and verify the checksum of the crate tar. We also enforce using HTTPS with TLS >= 1.2 for the actual download of the package files.

Compared to something like a curl ... | sh script, we're not running arbitrary code, but of course the crate you're downloading a package for might itself be malicious!

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

Are debug symbols available?

Yes! Extra pre-built packages with a .full suffix are available and contain split debuginfo, documentation files, and extra binaries like the detect-wasi utility.

---

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.

cargo-binstall's Issues

Feedback / Experience / Adventures meta-issue

A meta-issue for the experience of using this, if you have any thoughts / feelings / ideas please comment here!

Re-design a tad more carefully

Improve the design of this, follow-up from #9

• Support multiple parallel versions (install binaries with version suffix, update symlink)
• Avoid tar-explosions / overwriting things
  • Support specifying binaries to be extracted in Cargo.toml
  • Extract to temporary dir, check files are reasonable, ask for confirmation
• Support non-rust binary installs
  • Github / Gitlab releases should be easy (#4)
  • Other useful things? third party manifests?

And specify the behaviour in a Design section of the readme.

How to use `pkg-fmt = "bin"` ?

Hi,

i discovered this tool with cargo-tarpaulin, it's a great idea / tool !

---

i'm trying to add it to my crate which is hosted on GitLab

i added this to Cargo.toml

[package.metadata.binstall]
pkg-fmt = "bin"

[package.metadata.binstall.overrides.x86_64-unknown-linux-gnu]
pkg-url = "https://gitlab.com/api/v4/projects/24880317/packages/generic/{ name }-linux/{ version }/{ name }_v{ version }_x86_64_linux"

[package.metadata.binstall.overrides.x86_64-pc-windows-gnu]
pkg-url = "https://gitlab.com/api/v4/projects/24880317/packages/generic/{ name }-windows/{ version }/{ name }_v{ version }_x86_64_windows{ format }"

i tried to install my crate using this command cargo binstall --manifest-path=. --no-cleanup --no-confirm --log-level=debug git-gamble which gives this error

21:19:45 [INFO] Installing package: 'git-gamble'
21:19:45 [DEBUG] (1) cargo_binstall: Reading manifest: .
21:19:45 [DEBUG] (1) cargo_binstall::helpers: Reading manifest: ./Cargo.toml
21:19:45 [DEBUG] (1) cargo_binstall: Found metadata: PkgMeta { pkg_url: "https://gitlab.com/api/v4/projects/24880317/packages/generic/{ name }-linux/{ version }/{ name }_v{ version }_x86_64_linux", pkg_fmt: Bin, bin_dir: "{ name }-{ target }-v{ version }/{ bin }{ format }", pub_key: None, overrides: {"x86_64-pc-windows-gnu": PkgOverride { pkg_url: Some("https://gitlab.com/api/v4/projects/24880317/packages/generic/{ name }-windows/{ version }/{ name }_v{ version }_x86_64_windows{ format }"), pkg_fmt: None, bin_dir: None }} }
21:19:45 [DEBUG] (1) cargo_binstall: Using context: Context { name: "git-gamble", repo: Some("https://gitlab.com/pinage404/git-gamble"), target: "x86_64-unknown-linux-gnu", version: "0.100.11", format: "bin", bin: None }
21:19:45 [DEBUG] (1) cargo_binstall::helpers: using CARGO_HOME (/media/exec_downloaded/rust/cargo)
21:19:45 [DEBUG] (1) cargo_binstall: Using install path: /media/exec_downloaded/rust/cargo/bin
21:19:45 [INFO] Downloading package from: 'https://gitlab.com/api/v4/projects/24880317/packages/generic/git-gamble-linux/0.100.11/git-gamble_v0.100.11_x86_64_linux'
21:19:45 [DEBUG] (1) cargo_binstall::helpers: Downloading from: 'https://gitlab.com/api/v4/projects/24880317/packages/generic/git-gamble-linux/0.100.11/git-gamble_v0.100.11_x86_64_linux'
21:19:46 [DEBUG] (1) cargo_binstall::helpers: Download OK, writing to file: '"/run/user/1000/cargo-binstall.mq8elND2I8UU/pkg-git-gamble.bin"'
21:19:46 [DEBUG] (1) cargo_binstall::helpers: Copying binary '"/run/user/1000/cargo-binstall.mq8elND2I8UU/pkg-git-gamble.bin"' to `"/run/user/1000/cargo-binstall.mq8elND2I8UU/bin-git-gamble"`
21:19:46 [INFO] This will install the following binaries:
21:19:46 [INFO]   - git-gamble (git-gamble -> /media/exec_downloaded/rust/cargo/bin/git-gamble-v0.100.11)
21:19:46 [INFO] And create (or update) the following symlinks:
21:19:46 [INFO]   - git-gamble (/media/exec_downloaded/rust/cargo/bin/git-gamble-v0.100.11 -> /media/exec_downloaded/rust/cargo/bin/git-gamble)
21:19:46 [INFO] Installing binaries...
Error: Not a directory (os error 20)

i cloned cargo-binstall to try to understand how i misused it

i added some logs in the main function

        debug!("bin_path {:#?}", bin_path);
        debug!("source_file_path {:#?}", source_file_path);
        debug!("source {:#?}", source);

When i try again with this command cargo run -- --manifest-path=../git-gamble/ --no-cleanup --no-confirm --log-level=debug git-gamble which gives the same error

   Compiling cargo-binstall v0.4.1 (/home/pinage404/Project/cargo-binstall)
    Finished dev [unoptimized + debuginfo] target(s) in 7.24s
     Running `target/debug/cargo-binstall --manifest-path=../git-gamble/ --no-cleanup --no-confirm --log-level=debug git-gamble`
20:36:08 [INFO] Installing package: 'git-gamble'
20:36:08 [DEBUG] (1) cargo_binstall: Reading manifest: ../git-gamble/
20:36:08 [DEBUG] (1) cargo_binstall::helpers: Reading manifest: ../git-gamble/Cargo.toml
20:36:08 [DEBUG] (1) cargo_binstall: Found metadata: PkgMeta { pkg_url: "https://gitlab.com/api/v4/projects/24880317/packages/generic/{ name }-linux/{ version }/{ name }_v{ version }_x86_64_linux", pkg_fmt: Bin, bin_dir: "{ name }-{ target }-v{ version }/{ bin }{ format }", pub_key: None, overrides: {"x86_64-pc-windows-gnu": PkgOverride { pkg_url: Some("https://gitlab.com/api/v4/projects/24880317/packages/generic/{ name }-windows/{ version }/{ name }_v{ version }_x86_64_windows{ format }"), pkg_fmt: None, bin_dir: None }} }
20:36:08 [DEBUG] (1) cargo_binstall: Using context: Context { name: "git-gamble", repo: Some("https://gitlab.com/pinage404/git-gamble"), target: "x86_64-unknown-linux-gnu", version: "0.100.11", format: "bin", bin: None }
20:36:08 [DEBUG] (1) cargo_binstall::helpers: using CARGO_HOME (/media/exec_downloaded/rust/cargo)
20:36:08 [DEBUG] (1) cargo_binstall: Using install path: /media/exec_downloaded/rust/cargo/bin
20:36:08 [INFO] Downloading package from: 'https://gitlab.com/api/v4/projects/24880317/packages/generic/git-gamble-linux/0.100.11/git-gamble_v0.100.11_x86_64_linux'
20:36:08 [DEBUG] (1) cargo_binstall::helpers: Downloading from: 'https://gitlab.com/api/v4/projects/24880317/packages/generic/git-gamble-linux/0.100.11/git-gamble_v0.100.11_x86_64_linux'
20:36:08 [DEBUG] (1) cargo_binstall::helpers: Download OK, writing to file: '"/run/user/1000/cargo-binstall.dTMhO1z49g33/pkg-git-gamble.bin"'
20:36:08 [DEBUG] (1) cargo_binstall::helpers: Copying binary '"/run/user/1000/cargo-binstall.dTMhO1z49g33/pkg-git-gamble.bin"' to `"/run/user/1000/cargo-binstall.dTMhO1z49g33/bin-git-gamble"`
20:36:08 [DEBUG] (1) cargo_binstall: bin_path "/run/user/1000/cargo-binstall.dTMhO1z49g33/bin-git-gamble"
20:36:08 [DEBUG] (1) cargo_binstall: source_file_path "git-gamble-x86_64-unknown-linux-gnu-v0.100.11/git-gamble"
20:36:08 [DEBUG] (1) cargo_binstall: source "/run/user/1000/cargo-binstall.dTMhO1z49g33/bin-git-gamble/git-gamble-x86_64-unknown-linux-gnu-v0.100.11/git-gamble"
20:36:08 [INFO] This will install the following binaries:
20:36:08 [INFO]   - git-gamble (git-gamble -> /media/exec_downloaded/rust/cargo/bin/git-gamble-v0.100.11)
20:36:08 [INFO] And create (or update) the following symlinks:
20:36:08 [INFO]   - git-gamble (/media/exec_downloaded/rust/cargo/bin/git-gamble-v0.100.11 -> /media/exec_downloaded/rust/cargo/bin/git-gamble)
20:36:08 [INFO] Installing binaries...
Error: Not a directory (os error 20)

As far as i understand, cargo-binstall tries to access the binary file in the extracted folder ; but in this case, i have a simple binary file that is just copied by the extract function

https://github.com/ryankurte/cargo-binstall/blob/5c56c930e4209d00ea61b8c86b43e82b6da14ea1/src/helpers.rs#L90

In the main function, i replaced

-        let source = bin_path.join(&source_file_path);
+        let source = if meta.pkg_fmt == PkgFmt::Bin {
+            bin_path.clone()
+        } else {
+            bin_path.join(&source_file_path)
+        };

Then run the same cargo command again cargo run -- --manifest-path=../git-gamble/ --no-cleanup --no-confirm --log-level=debug git-gamble successfully

    Finished dev [unoptimized + debuginfo] target(s) in 0.10s
     Running `target/debug/cargo-binstall --manifest-path=../git-gamble/ --no-cleanup --no-confirm --log-level=debug git-gamble`
20:43:38 [INFO] Installing package: 'git-gamble'
20:43:38 [DEBUG] (1) cargo_binstall: Reading manifest: ../git-gamble/
20:43:38 [DEBUG] (1) cargo_binstall::helpers: Reading manifest: ../git-gamble/Cargo.toml
20:43:38 [DEBUG] (1) cargo_binstall: Found metadata: PkgMeta { pkg_url: "https://gitlab.com/api/v4/projects/24880317/packages/generic/{ name }-linux/{ version }/{ name }_v{ version }_x86_64_linux", pkg_fmt: Bin, bin_dir: "{ name }-{ target }-v{ version }/{ bin }{ format }", pub_key: None, overrides: {"x86_64-pc-windows-gnu": PkgOverride { pkg_url: Some("https://gitlab.com/api/v4/projects/24880317/packages/generic/{ name }-windows/{ version }/{ name }_v{ version }_x86_64_windows{ format }"), pkg_fmt: None, bin_dir: None }} }
20:43:38 [DEBUG] (1) cargo_binstall: Using context: Context { name: "git-gamble", repo: Some("https://gitlab.com/pinage404/git-gamble"), target: "x86_64-unknown-linux-gnu", version: "0.100.11", format: "bin", bin: None }
20:43:38 [DEBUG] (1) cargo_binstall::helpers: using CARGO_HOME (/media/exec_downloaded/rust/cargo)
20:43:38 [DEBUG] (1) cargo_binstall: Using install path: /media/exec_downloaded/rust/cargo/bin
20:43:38 [INFO] Downloading package from: 'https://gitlab.com/api/v4/projects/24880317/packages/generic/git-gamble-linux/0.100.11/git-gamble_v0.100.11_x86_64_linux'
20:43:38 [DEBUG] (1) cargo_binstall::helpers: Downloading from: 'https://gitlab.com/api/v4/projects/24880317/packages/generic/git-gamble-linux/0.100.11/git-gamble_v0.100.11_x86_64_linux'
20:43:38 [DEBUG] (1) cargo_binstall::helpers: Download OK, writing to file: '"/run/user/1000/cargo-binstall.5H2XUFetxoIQ/pkg-git-gamble.bin"'
20:43:38 [DEBUG] (1) cargo_binstall::helpers: Copying binary '"/run/user/1000/cargo-binstall.5H2XUFetxoIQ/pkg-git-gamble.bin"' to `"/run/user/1000/cargo-binstall.5H2XUFetxoIQ/bin-git-gamble"`
20:43:38 [DEBUG] (1) cargo_binstall: bin_path "/run/user/1000/cargo-binstall.5H2XUFetxoIQ/bin-git-gamble"
20:43:38 [DEBUG] (1) cargo_binstall: source_file_path "git-gamble-x86_64-unknown-linux-gnu-v0.100.11/git-gamble"
20:43:38 [DEBUG] (1) cargo_binstall: source "/run/user/1000/cargo-binstall.5H2XUFetxoIQ/bin-git-gamble"
20:43:38 [INFO] This will install the following binaries:
20:43:38 [INFO]   - git-gamble (bin-git-gamble -> /media/exec_downloaded/rust/cargo/bin/git-gamble-v0.100.11)
20:43:38 [INFO] And create (or update) the following symlinks:
20:43:38 [INFO]   - git-gamble (/media/exec_downloaded/rust/cargo/bin/git-gamble-v0.100.11 -> /media/exec_downloaded/rust/cargo/bin/git-gamble)
20:43:38 [INFO] Installing binaries...
20:43:38 [INFO] Installation complete!

Unfortunately, the binary is not usable because it does not have the execution mode when downloaded through cargo-binstall

exa -lh $CARGO_HOME/bin/*git-gamble*
Permissions Size User      Date Modified  Name
lrwxrwxrwx    58 pinage404 15 oct.  23:10 /media/exec_downloaded/rust/cargo/bin/git-gamble -> /media/exec_downloaded/rust/cargo/bin/git-gamble-v0.100.11
.rw-r--r--  768k pinage404 15 oct.  23:15 /media/exec_downloaded/rust/cargo/bin/git-gamble-v0.100.11

This problem can be solved by adding this in the main function

     for (_name, source, dest, _link) in &bin_files {
         // TODO: check if file already exists
         std::fs::copy(source, dest)?;
+        use std::os::unix::fs::PermissionsExt;
+        std::fs::set_permissions(dest, std::fs::Permissions::from_mode(0o755))?;
     }

---

How to use cargo-binstall with pkg-fmt = "bin" ?

Did i use it badly ?

Are there any bugs in this part ?

Swap actions vcpkg to run-vcpkg

Caching currently doesn't seem to work properly so windows builds are slowww, hopefully run-vcpkg would resolve this

Fix armv7 build

Waiting on actions/runner-images#1961 which should magically resolve this

Feature request: Support for wasm?

I wonder is it possible for cargo-binstall to run on wasm target and add wasm target as a fallback if the environment supports running wasm?

Investigate using cg_clif for debug builds in CI

Some benchmarking shows a significant speedup, from 30s on nightly to 23s on cg_clif. I'm doing some more benchmarking to check the numbers further.

Cannot load `libssl.so.1.1` on ubuntu 22.04 x86-64 for prebuilt binary

On ubuntu 22.04 x86-64, I followed the steps to install prebuilt binary and running it gives me error:

error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

Tracking of upstream bug in `tar`

alexcrichton/tar-rs#295

tar failed to handle GNUSparseFile correctly.

Garbage left in ~/.cargo/bin when SIGINTing out of the "continue?" question

c-i-t@tarta:~$ ls -la .cargo/bin/
total 18
drwxr-xr-x 2 c-i-t c-i-t 2 Aug  3 17:59 .
drwxr-xr-x 4 c-i-t c-i-t 7 Aug  3 17:56 ..
c-i-t@tarta:~$ strace -foss ./cargo-binstall cargo-update
16:00:55 [INFO] Installing package: 'cargo-update'
16:00:56 [INFO] Checking for package at: 'https://github.com/nabijaczleweli/cargo-update/releases/download/v8.1.4/cargo-update-x86_64-unknown-linux-gnu-v8.1.4.tar.gz'
16:00:56 [INFO] Checking for package at: 'https://github.com/alsuren/cargo-quickinstall/releases/download/cargo-update-8.1.4-x86_64-unknown-linux-gnu/cargo-update-8.1.4-x86_64-unknown-linux-gnu.tar.gz'
16:00:56 [INFO] Checking for package at: 'https://github.com/nabijaczleweli/cargo-update/releases/download/v8.1.4/cargo-update-x86_64-unknown-linux-musl-v8.1.4.tar.gz'
16:00:56 [INFO] Checking for package at: 'https://github.com/nabijaczleweli/cargo-update/releases/download/v8.1.4/cargo-update-x86_64-unknown-linux-musl-v8.1.4.tgz'
16:00:56 [INFO] Checking for package at: 'https://github.com/nabijaczleweli/cargo-update/releases/download/v8.1.4/cargo-update-x86_64-unknown-linux-gnu-v8.1.4.tgz'
16:00:56 [INFO] Checking for package at: 'https://github.com/alsuren/cargo-quickinstall/releases/download/cargo-update-8.1.4-x86_64-unknown-linux-musl/cargo-update-8.1.4-x86_64-unknown-linux-musl.tar.gz'
16:00:56 [WARN] The package will be downloaded from third-party source QuickInstall
16:00:56 [INFO] This will install the following binaries:
16:00:56 [INFO]   - cargo-install-update (cargo-install-update -> /home/c-i-t/.cargo/bin/cargo-install-update-v8.1.4)
16:00:56 [INFO]   - cargo-install-update-config (cargo-install-update-config -> /home/c-i-t/.cargo/bin/cargo-install-update-config-v8.1.4)
16:00:56 [INFO] And create (or update) the following symlinks:
16:00:56 [INFO]   - cargo-install-update (/home/c-i-t/.cargo/bin/cargo-install-update -> cargo-install-update-v8.1.4)
16:00:56 [INFO]   - cargo-install-update-config (/home/c-i-t/.cargo/bin/cargo-install-update-config -> cargo-install-update-config-v8.1.4)
Do you wish to continue? yes/[no]
? ^C
c-i-t@tarta:~$ ls -la .cargo/bin/
total 27
drwxr-xr-x 3 c-i-t c-i-t 3 Aug  3 18:00 .
drwxr-xr-x 4 c-i-t c-i-t 7 Aug  3 17:56 ..
drwxr-xr-x 2 c-i-t c-i-t 2 Aug  3 18:00 cargo-binstalliNbMeS
c-i-t@tarta:~$ ls -la .cargo/bin/cargo-binstalliNbMeS/
total 18
drwxr-xr-x 2 c-i-t c-i-t 2 Aug  3 18:00 .
drwxr-xr-x 3 c-i-t c-i-t 3 Aug  3 18:00 ..

strace -f

Aarch64 support

I know supporting more targets isn't fun and aarch64 platforms aren't used as much for things like ci, so theres no big reason for offering prebuilt binaries. If you don't mind, I have some questions.

• Is there a reason to not offer prebuilt binaries? Usage on devices such as newer 64bit raspberry pis, apple silicon macs, ...

In the process of looking into the repository and finding possible blockers I got some more questions:

• Was/Is there a reason why not to use cross for cross-compilation?
• Was/Is there a reasony not to use a vendored version of openssl for git2?
• Was/Is there a reason why crates_io_api uses openssl instead of rustls?

Bug in finding best download source

My CI for x86_64-unknown-linux-{gnu, musl} failed because "gzip header is invalid".

It is reproducible on the CI as I have restarted the fail tests for three times.

This bug is likely be caused by #236 @passcod .

Fails to install 2021 edition crates

I'm getting an error while trying to install crates which has edition = "2021" field in Cargo.toml:

$ cargo binstall --dry-run kmon
16:49:53 [INFO] Installing package: 'kmon'
Error: unknown variant `2021`, expected `2015` or `2018` for key `package.edition` at line 70 column 1

Caused by:
    unknown variant `2021`, expected `2015` or `2018` for key `package.edition` at line 70 column 1

Support installation via github-release API

This is somewhat different to existing mechanisms that pull the crate and metadata first, however, it should be possible to:

• Query github release API for releases
• Filter for matching version constraints
• Download default asset

Not sure how this interacts with signing / where one would expect the signing key to be in this case.

Help doesn't show when invoking with no arguments

$ cargo binstall
Do you wish to continue? yes/[no]
?
08:36:52 [WARN] Installation cancelled

We should show the help if we have no crates to install.

Investigation required: Compilation of `cargo-binstall (bin)` taking way too long

Since the CI of this project usually takes >5m, I decided to take advice from Making a Rust crate compile faster and use cargo b --release --timings.

The result is shocking as roughly half of the time is spent in building the binary cargo-binstall.

Memory corruption(? well, probably not; random name though) -> inscrutable error on plain unpack

This is on a clean new user:

c-i-t@tarta:~$ wget https://github.com/ryankurte/cargo-binstall/releases/latest/download/cargo-binstall-x86_64-unknown-linux-musl.tgz
...
2022-08-03 17:23:47 (2.33 MB/s) - ‘cargo-binstall-x86_64-unknown-linux-musl.tgz’ saved [2492469/2492469]

c-i-t@tarta:~$ tar -tvaf cargo-binstall-x86_64-unknown-linux-musl.tgz
-rw-r--r-- runner/docker 35149 2022-07-24 10:48 LICENSE.txt
-rw-r--r-- runner/docker 10668 2022-07-24 10:48 README.md
-rwxr-xr-x runner/docker 5264960 2022-07-24 10:48 cargo-binstall
c-i-t@tarta:~$ tar -xvaf cargo-binstall-x86_64-unknown-linux-musl.tgz  cargo-binstall
cargo-binstall
c-i-t@tarta:~$ ./cargo-binstall
15:24:11 [ERROR] Fatal error:
binstall::io (https://docs.rs/cargo-binstall/0.11.1/cargo_binstall/enum.BinstallError.html#variant.Io)

  × No such file or directory (os error 2) at path "/home/c-i-t/.cargo/bin/cargo-binstalleMdRRS"

It looks like memory corruption but probably isn't, considering, so it's probably some random name? Either way, not sure what's supposed to happen here, but it's not that.

strace -f; --log-level=debug:

c-i-t@tarta:~$ ./cargo-binstall --log-level=debug
15:29:28 [DEBUG] (25) cargo_binstall::helpers: using (/home/c-i-t/.cargo) as cargo home
15:29:28 [DEBUG] (25) cargo_binstall: Using install path: /home/c-i-t/.cargo/bin
15:29:28 [DEBUG] (1) cargo_binstall: run time: 3.040425ms
15:29:28 [ERROR] Fatal error:
binstall::io (https://docs.rs/cargo-binstall/0.11.1/cargo_binstall/enum.BinstallError.html#variant.Io)

  × No such file or directory (os error 2) at path "/home/c-i-t/.cargo/bin/cargo-binstallIwSQUG"

Deprecate --version and add support for -v

--version is misleading taiki-e/install-action#14

And cargo-binstall needs a -v to obtain its version easily.

opt-out options

From a usability, testability and relyability point of view, I would like to be able to tell cargo-binstall which sources should be used.

With the current setup, all fallbacks are enabled by default. If I use --no-confirm, it will either use the crates binstall metadata, search on quickinstall or fallback to installing via cargo install. As this might be good for people who "just wanna install it", this means the goal of installing a pre-built binary might be missed.

What I do propose is not a falg to enable fallbacks, but rather flags to disable or exlude fallback:

• --no-third-party-sources to exlude third party installs
• --disable-cargo-install to just disable the fallback on cargo install

#133

`Error: relative URL without a base` installing `systemfd`

cargo binstall systemfd fails with a cryptic error:

15:25:56 [INFO] Installing package: 'systemfd'
Error: relative URL without a base

With debug logging, cargo binstall systemfd --log-level=debug:

14:51:29 [INFO] Installing package: 'systemfd'
14:51:29 [DEBUG] (1) cargo_binstall::drivers: Updating crates.io index
14:51:29 [DEBUG] (1) cargo_binstall::drivers: Looking up crate information
14:51:29 [DEBUG] (1) cargo_binstall::drivers: Version: Version { major: 0, minor: 1, patch: 0 }
14:51:29 [DEBUG] (1) cargo_binstall::drivers: Version: Version { major: 0, minor: 2, patch: 0 }
14:51:29 [DEBUG] (1) cargo_binstall::drivers: Version: Version { major: 0, minor: 3, patch: 0 }
14:51:29 [DEBUG] (1) cargo_binstall::drivers: Version: Version { major: 0, minor: 4, patch: 0 }
14:51:29 [DEBUG] (1) cargo_binstall::drivers: Filtered: ["0.4.0", "0.3.0", "0.2.0", "0.1.0"]
14:51:29 [DEBUG] (1) cargo_binstall::drivers: Found information for crate version: '0.4.0'
14:51:29 [DEBUG] (1) cargo_binstall::drivers: Fetching crate from: https://crates.io//api/v1/crates/systemfd/0.4.0/download
14:51:29 [DEBUG] (1) cargo_binstall::helpers: Downloading from: 'https://crates.io//api/v1/crates/systemfd/0.4.0/download'
14:51:30 [DEBUG] (1) cargo_binstall::helpers: Download OK, writing to file: '/tmp/cargo-binstall.KF5Rr0Z2d9N4/systemfd.tgz'
14:51:30 [DEBUG] (1) cargo_binstall::drivers: Decompressing crate archive
14:51:30 [DEBUG] (1) cargo_binstall::helpers: Decompressing from tgz archive '"/tmp/cargo-binstall.KF5Rr0Z2d9N4/systemfd.tgz"' to `"/tmp/cargo-binstall.KF5Rr0Z2d9N4"`
14:51:30 [DEBUG] (1) cargo_binstall: Reading manifest: /tmp/cargo-binstall.KF5Rr0Z2d9N4/systemfd-0.4.0
14:51:30 [DEBUG] (1) cargo_binstall::helpers: Reading manifest: /tmp/cargo-binstall.KF5Rr0Z2d9N4/systemfd-0.4.0/Cargo.toml
14:51:30 [DEBUG] (1) cargo_binstall: Found metadata: PkgMeta { pkg_url: "{ repo }/releases/download/v{ version }/{ name }-{ target }-v{ version }.{ archive-format }", pkg_fmt: Tgz, bin_dir: "{ name }-{ target }-v{ version }/{ bin }{ binary-ext }", pub_key: None, overrides: {} }
14:51:30 [DEBUG] (1) cargo_binstall::helpers: using CARGO_HOME (/home/vscode/.cargo)
14:51:30 [DEBUG] (1) cargo_binstall: Using install path: /home/vscode/.cargo/bin
14:51:30 [DEBUG] (1) cargo_binstall: Using temporary download path: /tmp/cargo-binstall.KF5Rr0Z2d9N4/pkg-systemfd.tgz
14:51:30 [DEBUG] (1) cargo_binstall::fetchers::gh_crate_meta: Using context: Context { name: "systemfd", repo: None, target: "x86_64-unknown-linux-gnu", version: "0.4.0", format: "tgz", archive_format: "tgz", binary_ext: "" }
Error: relative URL without a base

Related: #108

Only https for requests

Quickly looking over some request code, it seems to me that binaries are also allowed to be downloaded over http. Am I missing something? Is there are reason to allow this? reqwest has a client builder flag https_only but it is disabled by default

ssh failure when attempting to install cargo-watch

I get the error below when trying to install cargo-watch:

cargo binstall cargo-watch
11:17:18 [INFO] Installing package: 'cargo-watch'
Error: authentication required but no callback set; class=Ssh (23)

I found this related issue rust-lang/git2-rs#329.

`Error: No viable remote package found` fallback wanted: `cargo install`

TL;DR, binstall fails when quickinstall release is missing or when other errors occur. Instead of failing, I'd like a fallback option that tries cargo install before giving up.

Overall this project is really promising! I have a dozen or so changes like this that I want to make to my Dockerfile:

-wget -q https://github.com/watchexec/watchexec/releases/download/cli-v1.18.6/watchexec-1.18.6-x86_64-unknown-linux-musl.tar.xz -O - | tar xJ watchexec-1.18.6-x86_64-unknown-linux-musl/watchexec --strip-components=1
+cargo binstall --no-confirm watchexec --version 1.18.6

However, I've found that several of my packages neither have binstall metadata nor are they cached on https://github.com/alsuren/cargo-quickinstall/releases.

cargo binstall --no-confirm watchexec                 
14:57:13 [INFO] Installing package: 'watchexec'
14:57:13 [INFO] Checking for package at: 'https://github.com/watchexec/watchexec/releases/download/v1.17.1/watchexec-x86_64-unknown-linux-gnu-v1.17.1.tgz'
14:57:14 [INFO] Sending installation report to quickinstall (anonymous)
14:57:15 [INFO] Checking for package at: 'https://github.com/alsuren/cargo-quickinstall/releases/download/watchexec-1.17.1-x86_64-unknown-linux-gnu/watchexec-1.17.1-x86_64-unknown-linux-gnu.tar.gz'
14:57:16 [ERROR] File does not exist remotely, cannot proceed
Error: No viable remote package found

For context, here's the cargo-quickinstall docs:

If we don't have a pre-compiled version, it will fallback to cargo install automatically.

Does binstall intentionally lack that behavior? If so, it might be nice to have a note about that on the README; I expected a fallback, considering this project's relationship to quickinstall. If not, consider this a feature request.

"reference 'refs/heads/master' not found" on debian

On debian bullseye docker image, I installed rustup and let it installed the latest stable version of cargo for me, then I followed the steps to install prebuilt version of cargo-binstall.

When I ran ./cargo-binstall binstall --log-level debug radio-sx128x:

04:31:37 [INFO] Installing package: 'radio-sx128x'
04:31:37 [DEBUG] (1) cargo_binstall::drivers: Updating crates.io index
Error: reference 'refs/heads/master' not found; class=Reference (4); code=NotFound (-3)

Caused by:
    reference 'refs/heads/master' not found; class=Reference (4); code=NotFound (-3)

If I pulled the official rust docker image, then everything works just fine.

Getting wrid of `tempdir`

tempdir itself is unmaintained since 2018 and since has been moved into tempfile.

Looking at the situation in general.
The current code tries to download the file from the source, loads it's bytes into memory, saves it to disk, unpacks it, reads 1 (or a few) files and (if not disabled) removes the temporary directory.

While I do see a benefit of debuggability it could also be another attack surface and IMO an unneeded roundtrip. What I do propose is: download, extract needed file(s), save it/them.

Would love to have feedback on this 🦄

#130

Custom extension for format

Tangentially related to #37.

Currently the Tgz format assumes the .tgz extension, but it might instead be .tar.gz.

In the current state, one may simply not use the { format } specifier for the URL and add the correct extension there directly. However, with some solution to #37 there's going to be a need for this mapping!

Different archive format on a platform

Cargo-watch provides Zips on Windows to make it trivial for humans to install, and tar.xz elsewhere because it's expected that's available.

I suppose a workaround in the meantime would be to provide both zip and tar.xz windows builds :/

Handle not found / unconfigured case more gracefully

If a repository is not configured correctly for binstall you'll get a variety of different and interesting errors. This should be improved with guidance as to how they may be resolved.

Proper exit codes

As mentioned in #113 and #116 many statments in main.rs after an if clause to determine if it should abort use return Ok(()); which ends the process but exits with the exit code 0. This makes it hard for scripts like Dockerfile or github actions to abort if cargo binstall couldn't find a correct version.

Changing this to return Err(anyhow::anyhow!("Installation cancelled")); would be a easy thing to do but in case of the provided example this would output the following thing:

gitpod /workspace/cargo-binstall (fix/package-version-abort-logic) $ cargo binstall cargo-watch --version 8.1.0 --no-confirm
09:50:31 [INFO] Installing package: 'cargo-watch'
09:50:32 [WARN] You specified `--version 8.1.0` but the package resolved that to '8.1.1', use `=8.1.0` if you want an exact match
09:50:32 [WARN] Installation cancelled
Error: Installation cancelled

This means once the message via a warn!, nicely formatted and once plain as it is returned from main() -> Result<(), anyhow::Error>.

My 2 cents about a solution:

• It would be awesome to be able to format the output of anyhow, but I haven't found a solution yet
• Aiming for developers, this might be a no brainer as humans can read, but aiming for ci solutions, exit codes are critical

I appreciate comments and opinions, as I currently do not have a nice solution to propose

Installed symlinks are absolute? Also: weird symlink directionality in install message?

This is more of a question than a comment:

testpsko@tarta:~$ ls -l .cargo/bin/
total 82339
-rwxr-xr-x 12 testpsko testpsko 15690192 Mar 13 16:08 cargo
-rwxr-xr-x  1 testpsko testpsko 14018368 Mar 13 16:10 cargo-binstall
-rwxr-xr-x 12 testpsko testpsko 15690192 Mar 13 16:08 cargo-clippy
-rwxr-xr-x 12 testpsko testpsko 15690192 Mar 13 16:08 cargo-fmt
-rwxr-xr-x 12 testpsko testpsko 15690192 Mar 13 16:08 cargo-miri
-rwxr-xr-x 12 testpsko testpsko 15690192 Mar 13 16:08 clippy-driver
-rwxr-xr-x 12 testpsko testpsko 15690192 Mar 13 16:08 rls
-rwxr-xr-x 12 testpsko testpsko 15690192 Mar 13 16:08 rustc
-rwxr-xr-x 12 testpsko testpsko 15690192 Mar 13 16:08 rustdoc
-rwxr-xr-x 12 testpsko testpsko 15690192 Mar 13 16:08 rustfmt
-rwxr-xr-x 12 testpsko testpsko 15690192 Mar 13 16:08 rust-gdb
-rwxr-xr-x 12 testpsko testpsko 15690192 Mar 13 16:08 rust-lldb
-rwxr-xr-x 12 testpsko testpsko 15690192 Mar 13 16:08 rustup
lrwxrwxrwx  1 testpsko testpsko       45 Mar 13 16:11 sx128x-util -> /home/testpsko/.cargo/bin/sx128x-util-v0.17.2
-rwxr-xr-x  1 testpsko testpsko  6887720 Mar 13 16:11 sx128x-util-v0.17.2

Is there a good reason to do this? It will break if you move the bindir.

Similarly:

testpsko@tarta:~/cargo-binstall$ ./target/debug/cargo-binstall binstall radio-sx128x
15:23:46 [INFO] Installing package: 'radio-sx128x'
15:23:48 [INFO] Checking for package at: 'https://github.com/rust-iot/rust-radio-sx128x/releases/download/v0.17.2/sx128x-util-x86_64-unknown-linux-gnu.tgz'
15:23:49 [INFO] The package will be downloaded from github.com
15:23:49 [INFO] Downloading package from: 'https://github.com/rust-iot/rust-radio-sx128x/releases/download/v0.17.2/sx128x-util-x86_64-unknown-linux-gnu.tgz'
15:23:51 [INFO] This will install the following binaries:
15:23:51 [INFO]   - sx128x-util (sx128x-util-x86_64-unknown-linux-gnu -> /home/testpsko/.cargo/bin/sx128x-util-v0.17.2)
15:23:51 [INFO] And create (or update) the following symlinks:
15:23:51 [INFO]   - sx128x-util (/home/testpsko/.cargo/bin/sx128x-util-v0.17.2 -> /home/testpsko/.cargo/bin/sx128x-util)
15:23:51 [INFO] Do you wish to continue? yes/no

The direction is wrong here: basename ponts to basename-ver.

No warning/error/abort if version does not exist/is yanked

I just started out trying to create scripts to download a specific version of a package. During testing, I found out that the following command will succeed and install another version than specified.

cargo binstall cargo-watch --no-confirm --version 8.1.0
11:41:07 [INFO] Installing package: 'cargo-watch'
11:41:11 [INFO] Checking for package at: 'https://github.com/watchexec/cargo-watch/releases/download/v8.1.1/cargo-watch-v8.1.1-x86_64-apple-darwin.tar.xz'
11:41:12 [INFO] The package will be downloaded from github.com
11:41:12 [INFO] Downloading package from: 'https://github.com/watchexec/cargo-watch/releases/download/v8.1.1/cargo-watch-v8.1.1-x86_64-apple-darwin.tar.xz'
11:41:13 [INFO] This will install the following binaries:
11:41:13 [INFO]   - cargo-watch (cargo-watch -> /Users/chris/.cargo/bin/cargo-watch-v8.1.1)
11:41:13 [INFO] And create (or update) the following symlinks:
11:41:13 [INFO]   - cargo-watch (/Users/chris/.cargo/bin/cargo-watch-v8.1.1 -> /Users/chris/.cargo/bin/cargo-watch)
11:41:13 [INFO] Installing binaries...
11:41:13 [INFO] Installation complete!

I understand that it's looking for ^8.1.0 but my 2 cents:

• Either it should warn the user and offer other versions as options similar to npx or yarn add or in case of --no-confirm abort
• Or clarify how its searching and also add that to the help page and keep error messages such as Error: No matching version for requirement: '=8.0.1' in line with others

I know I'm a bit picky on versioning and there is a reason semver versioning exists but there is also a reason why they gave it multiple digits to use. If I'm searching for some milk in a supermarket, I do not expect to leave with a yogurt just cause they are similar

Happy to hear opinions and RTFMs

Move to an org and fork some crates

Upstream jobserver has a longstanding bug relating to lifetime of Client rust-lang/jobserver-rs#25

I submit a solution for fixing this rust-lang/jobserver-rs#40 which unfortunately was rejected due to changing of its interface.

While use of jobserver in cargo-binstall is currently ok and does not trigger the bug, I would still like it to be fixed and the PR I mentioned also improve performance of spawning a new process since it can use posix_spawn on unix (which can use vfork on linux).

Support third-party / unofficial builds

In some cases the package maintainers may not wish to add support for this, or the CI outputs may not contain the correct / required binaries. It would be used to have an unofficial manifest to allow the building and distribution of these packages in a useful way.

This could be accomplished through the creation of a binstall-unofficial repository, configured with gh-actions to build and package unsupported projects (following the default binstall format).
Passing the --unofficial argument should then perform package discovery in the same manner, but use the packages published to the unofficial repository.

Questions:

• Is this useful?
  • I think yes (no more compiling sccache on armhf!)
• Is a github release the best way of doing this?
  • Unsure, as package versions will not correlate with releases it might be more useful to publish to a gh-pages site for tracability
• Should --unofficial override existing packages?
  • Probably not, at least not without an override
• Would it be useful to support third party / private packages?
  • Aid in the distribution of internal packages etc.
• Additional manifests vs. files in the right places?
  • Not sure, manifest probably required to support the private case as we can't pull data from crates.io / gh in this case

Possible UI / UX improvements?

playing with this on arm64 and i think we could re-evaluate the UI a little bit, maybe improve the balance between debug / info and streamline what the user actually -sees-

at the moment this looks something like:

> pi@pi-sx128x-01:~ $ cargo binstall radio-sx128x
22:13:19 [INFO] Installing package: 'radio-sx128x'
22:13:22 [INFO] Checking for package at: 'https://github.com/rust-iot/rust-radio-sx128x/releases/download/v0.18.0/sx128x-util-aarch64-unknown-linux-gnu.tgz'
22:13:22 [INFO] Sending installation report to quickinstall (anonymous)
22:13:24 [INFO] Checking for package at: 'https://github.com/alsuren/cargo-quickinstall/releases/download/radio-sx128x-0.18.0-aarch64-unknown-linux-gnu/radio-sx128x-0.18.0-aarch64-unknown-linux-gnu.tar.gz'
22:13:24 [WARN] The package will be installed from source (with cargo)
22:13:24 [INFO] Do you wish to continue? yes/[no]
? no
22:13:25 [WARN] Installation cancelled

i think most of this is a relic of debugging when i started writing this, also i am not sure but it -seems- like we're reporting to quickinstall even when not finding a matching package?

so i guess the real question is how would we -like- this to look? i'm imagining something more modern-package-manager?

> pi@pi-sx128x-01:~ $ cargo binstall radio-sx128x
**Installing package: 'radio-sx128x' (version: [VERSION])**
Checking for github release...               [tick]
Checking for quickinstall package...     [tick]
  Downloading via quickinstall...           [spinner]
[...]

Use `build-std` to reduce binar size

Using build-std feature on my MBA 2020 further trims 0.4M from release build:

cargo +nightly build -Z build-std=std,panic_abort -Z build-std-features=panic_immediate_abort --release --target aarch64-apple-darwin

Feature: Batch installation

On CI, it is often desirable to install all binaries it depended on at once ASAP.

Currently, cargo-binstall has to be invoked multiple times for multiple binaries, which is sequential and wastes time doing repeated works like pulling from https://crates.io .

I propose a new interface for batch installation:

cargo-binstall --no-confirm --batch cargo-watch:8.1.0 cargo-binstall

Binstall `musl` and `gnu` builds not compatible due to derived target from build options

hey folks, thanks (particularly @somehowchris, @NobodyXu and @passcod) for all your excellent work on improvements and getting a release out!

the musl binaries are a neat addition, but not technically compatible with the gnu versions because by default we use the target (injected via build.rs) to determine what binaries we'd like to install...

i think the best approach to resolving this is probably to trim the gnu and musl parts of the target and perform a check for both, defaulting to the one that matches out build with user selection if we're running interactively.
(also it would be nice to still build the gnu binaries, the cursed nightmares related to armv7 and aarch64 is why we weren't initially using cross, maybe a mix of both approaches would do the trick).

i'll try to have a look at it sometime soon but, posting an issue in case one of y'all gets there first ^_^

Allow downloading unsupported packages by overriding the templates at run time

Hi there, I would like to be able to support crates that haven't yet added explicit support for this tool.

One way to do this would be to override the pkg-url, bin-path, and pkg-format values from cli arguments.

I went ahead and implemented this functionality, I will open a PR momentarily. I am a new rustacean and would love some feedback. Thanks!

Segmentation Fault

It gets this far...

[asdf@asdf-computer ~]$ cargo binstall just
16:10:37 [INFO] Installing package: 'just'
Segmentation fault (core dumped)

This is on version 0.6.2 from a cargo install --locked binary.

Tar.xz support

Cargo-watch uses tar.xz

I'm unclear as to if that's supported under the "Tar" format mentioned in the readme.

Add a way to check for and install updates

This tool currently does not have a way to update all outdated packages ala apt upgrade.

It might be worth coordinating with the cargo-update project here. There was a feature request for this in that project but it's been rejected due to binstall not keeping track of what's installed from what package in any way and only simply copying the binaries into ~/.cargo/bin.

I feel like it could be a good idea to make cargo binstall work more like cargo install and update .crates.toml as well as .crates2.json. Then it would only be a matter of asking cargo-update project to allow a way to use cargo binstall instead of cargo install as the rest of its logic for update checking wouldn't require any changes.

I believe that once this change (creating .crates.toml and .crates2.json) were made, it would technically be possible to write a simple wrapper binary that proxies cargo and cargo binstall appropriately and pass that binary's name to cargo install-update using --install-cargo flag that allow specifying alternative cargo to run for installations. Obviously it would be better for cargo-update project to support it natively but I feel it's worth pointing out that even without them doing their part, this would still be helpful.

Universal binary with Cosmopolitan Libc

I just come acrossed this article, which reminds me of Cosmopolitan Libc, which IMHO is very amazing and jaw-dropping.

If we can have a cosmopolitan libc target, then doesn't that mean the installation of cargo-binstall itself would be much easier, we just need to find out the architecture.

The scripts for doing that will also be much easier, I think this is worth exploring.

The code for the article is in rust-ape-example.

Feature: install from manifest

Make a new manifest that specifies a list of crates/tools to be installed. The intent is both to keep a system/user-wide list of tools with versions for local use, and also a list of project-specific tools in a format that can be checked into version control. There should also be a lockfile, for the same mechanism as Cargo deps: version requirements in the manifest, and exact versions in the lockfile.

• The lockfile could also include URLs and checksums, providing a measure of security even without signing.
• It would be nice to have a set of tools like cargo add, cargo rm to manipulate the manifest.
• Needing to manipulate the lockfile points to a wider set of commands than the simple cargo binstall interface can accommodate.
• We could embed the manifest in the Cargo.toml, or have our own file. We'll definitely need our own file as a lockfile, so it could make more sense to have our own manifest file.
• Out of scope: non-crate tools. E.g. installing valgrind is not our concern.

I think this would be highly valued, and generally be very useful, not just for cargo projects.

---

I propose (and am working on) the following:

• A new tool under this project umbrella, cargo tools (a cargo-tools crate exists, but isn't used).
• A new manifest file, Tools.kdl, and its NLJSON lockfile, Tools.lock
• Default command cargo tools would print the status (what's installed, what isn't, what can be updated, what can be removed) and an interactive prompt to do something about it (choices: install as lockfile, update compatible, update breaking, do nothing). That way 90% of the time all you want to do is run cargo tools.
• A suite of subcommands: cargo tools add, cargo tools rm, cargo tools install, cargo tools update, cargo tools init, cargo tools status, etc

Manifest:

.version 1 // not required

.defaults {
    // Where to install binaries, defaults to `./bin` for projects and to `$HOME/.cargo/bin` for global
    install-into "./vendor"
}

// with version requirement
cargo-binstall version="0.9.1"

// when just any version will do
cargo-watch

// override defaults for this particular tool
watchexec {
    install-into "./bin"
}

A typical manifest could look like:

cargo-binstall
cargo-watch
cargo-make
cargo-edit
cargo-deb version="1.39.1"
cargo-generate-rpm version="0.8.0"

Sample of lockfile (pretty-printed for readability, each top level object would be its own line):

{"version":1}
{"req":{
  "name":"cargo-binstall",
  "version":"0.9.1",
  "metadata":"crates.io",
  "source":"repository",
  "template":{"pkg-fmt":"..."},
  "install-into":"./vendor"
},"pkg":[{
  "version":"0.9.1",
  "target":"x86_64-unknown-linux-musl",
  "source":"https://github.com/ryankurte/cargo-binstall/releases/v0.9.1/download/cargo-binstall-x86_64-unknown-linux-musl.tgz",
  "checksums":{"b3":"c5cd314cea5aca5391427bf9885d11f1fbc86d79679353a36d1b89480422149d"},
  "bins":["cargo-binstall"]
}]}

It's not practical to look for and download all available targets, so only the ones that are installed by the host / runner are written to the lockfile. When a user on a different host target runs cargo install, new files are downloaded and added to the lockfile; this prints a warning/notice to the console. If running with --locked, this causes an error instead. --keep-version is the middle ground, allowing versions to be kept exactly the same as locked, but new files to be downloaded if their target is not in the lockfile already.

Bug/Cannot find manifest

On my macbook air 2020, there's some strange behavior:

cargo run --release -- $tool

fails with binstall::cargo_manifest.

I tested with $tool set to either cargo-binstall or cargo-watch, both failed with this error message.

After bisecting, I figured out the bug, it's from #168 b6bfd40

Drop the version number from release binaries?

Hi there!

I'm interested in using cargo binstall for some of my release binaries. I noticed that https://github.com/ryankurte/cargo-binstall/releases/tag/v0.3.0 has the version number tacked onto the end -- I'm wondering if it's possible to skip that so that a simple curl from the right path works.

It looks like earlier versions are structured this way: https://github.com/ryankurte/cargo-binstall/releases/tag/v0.2.0 so maybe it's just a small fix :)

`AsyncExtracter` TODOs

A summary of what could be/need to be improved:

• Adjust the size of the mpsc::channel to keep the extracter busy while avoiding reading in too much (OOM) and gives feedback to the server. Fix could be dynamically decide the buffer based on fmt: PkgFmt since some extracters (PkgFmg::Bin and PkgFmt::Zip) do less work on the critical path and need bigger buffer size. Completely remove the mpsc channel, runs the downloader and extracter on the same thread. #180
• Exploring other channels, like single-producer single-consumer thread-safe fixed-size channel, since it is likely to be much faster than mpsc which requires synchronization between producers. Most likely to be premature optimization.
• The aforementioned of improvement "the ZipArchiver can read bytes out of the file while the bytes are being appended into the file." We should request for the feature in upstream instead of coming up with homebrew solution zip-rs/zip-old#16 zip-rs/zip-old#314
• Split API extract_archive_stream: Create a separate API for PkgFmt::Bin. #180

Symlinks on windows do not have .exe extension

Description

Currently symlinks are created without .exe extension on windows, which leads to unexpected behavior.
Without the extension they are launched in a separate process/window and tools like cargo-watch will not be detected when launched with cargo.

Example

> cargo binstall cargo-watch
[...]

> cargo watch -h
error: no such subcommand: `watch`

        Did you mean `fetch`?

> cargo-watch -h
[gets launched in a separate process/window]

Adding .exe to the symlink fixes the problem.

> mv ~\.cargo\bin\cargo-watch ~\.cargo\bin\cargo-watch.exe
> cargo watch -h
cargo-watch 8.1.1
https://watchexec.github.io/#cargo-watch
Watches over your Cargo project’s source
[...]

Support install directly from git repo

Fetch metadata from a git repository to support binary installation of unpublished crates

Support package signing and verification

It should be pretty easy to have a basic flow so CI created images can be signed, and verified on pull. Not sure what algorithm(s) / tools we should use? Accessibility is key, both IRL and in CI, and it needs to all work well cross-platform.

• Add public key (and key type?) to metadata (let's b64 it or something)
• Search for a signature file corresponding to each package (.sig or appropriate to the format)
• Generate checksum / validate signature against public key on pull

Issue probably related to symlink on Windows 11?

Hey,

I had issues with compiling cargo-watch that led me to try using cargo-binstall and I stumbled upon issues with appears to be caused by symlink. Full back story can be found watchexec/cargo-watch#196

In short I had to remove the symlink file to cargo-watch and rename the exe to cargo-watch.exe only then did the command cargo watch ... became recognized.

Let me know if there need for any additional information