Support installation via github-release API

[ryankurte]

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.

[passcod]

More discussion / context that was misplaced into #18:

ryan:

i think we could improve this in the case where there is a public build on github (if pkg-url and bin-path are not set) by requesting the list of files from the github API and finding the best match.

for example, cargo binstall mdbook currently tries to fetch the asset from:

https://github.com/rust-lang/mdBook/releases/download/v0.4.14/mdbook-x86_64-unknown-linux-gnu-v0.4.14.tgz

when the actual asset is:

https://github.com/rust-lang/mdBook/releases/download/v0.4.14/mdbook-v0.4.14-x86_64-unknown-linux-gnu.tar.gz

which we could locate with a GH API request like:

➜  ~ curl -sH "Accept: application/vnd.github.v3+json" https://api.github.com/repos/rust-lang/mdbook/releases/tags/v0.4.14 | jq '.assets[] | .name'
"mdbook-v0.4.14-x86_64-apple-darwin.tar.gz"
"mdbook-v0.4.14-x86_64-pc-windows-msvc.zip"
"mdbook-v0.4.14-x86_64-unknown-linux-gnu.tar.gz"

if we filter by architecture we should be able to work out the archive extension to extract, then have a nosey in the extracted directory to try to find a matching binary in the root or any subfolders.

does this seem like a reasonable thing to do? would remove the need for metadata for a bunch of use cases and i think be a useful step towards supporting installation by specifying a git repo, but does involve more magic (tm) than the current approach and will (for now) only work for github.

passcod:

I think it does sound like a good approach. I see it less as magic than "cargo binstall will try to do the right thing without configuration".

But looking forward: with this direction, eventually we could expect that most configuration becomes unnecessary, so long as the packaging is done along reasonable lines, with the config being only for overrides or unsupported discovery. So it's really about if the design intent is to go that way, or if binstall would prefer to have explicit opt-in and configuration.

ryan:

But looking forward: with this direction, eventually we could expect that most configuration becomes unnecessary, so long as the packaging is done along reasonable lines, with the config being only for overrides or unsupported discovery

that sounds pretty ideal to me, tools that just work (tm) but let you have explicit control if you need.

[somehowchris]

I agree with @passcod this seems to be well covered by quickinstall and my opinion for a tooling like cargo-binstall would be to have as few biases (and magic) for binary hosts as this would make it also harder for security people to debug the process of installs

Yes @passcod I agree that there could be "the default settings" and configs are just an overwrite, but for this case I believe there needs to be more done on the side of examples on how to provide binaries in todos or tooling (working on a gh action to build and upload binaries in a default setting for x targets in a other project)

I see the bias on crates.io as a big one, not only for this projects but for rust/cargo itself. I see the adoption of something like #3 (and possibly authentication for git and binary hosts) as a big move twords adoption for business use. If thats something you would accept or rather dispise, thats up to you

[NobodyXu]

One problem with this approach is that we cannot obtain the Cargo.toml, which also means we cannot obtain the list of binaries to install.

[ryankurte]

the releases API provides a list of assets, which we could also use in #295, so it'd basically just be skipping a discovery step

[NobodyXu]

the releases API provides a list of assets, which we could also use in #295, so it'd basically just be skipping a discovery step

So the releases API is only used to speedup the existing process, but does not add any new feature, such as installing unpublished crates that are available on github-release?

[passcod]

Yes, that makes a lot more sense, I think. With #3 we'll still want to read the Cargo.toml from the repo, which covers the unpublished crate usecase. Installing from random repos that happen to have artifacts in... some kind of format... is a bit too far I think.

[passcod]

Hmm I think that's done now.