Add package metadata for cargo-binstall

[swlynch99]

Hello! I've been using cargo-binstall to install hurl in CI. It is able to use release artifacts to install the required binaries without needing to rebuild the binary from scratch. Unfortunately, cargo-binstall isn't able to use the release artifacts you have published because the binaries aren't in a location it checks. (I think this previously worked because there is a pre-built binary cache over in cargo-quickinstall).

This PR adds some package metadata which cargo-binstall can use to download the release binaries directly from your release artifacts.

You can verify that this works yourself by running

cargo binstall --dry-run --manifest-path /path/to/hurl/repo hurl
cargo binstall --dry-run --manifest-path /path/to/hurl/repo hurlfmt

If it works correctly you should a line containing

 WARN The package hurl v5.0.1 (x86_64-unknown-linux-gnu) has been downloaded from github.com

[jcamiel]

Thanks for the PR @swlynch99. To appease our CI, we need all the commits to be signed (you can check CONTRIBUTING.md). You can see how to do this here , your commit should display a "verified" tag:

[swlynch99]

I have pushed a new signed commit.

[jcamiel]

Hi @swlynch99

Sorry for the delayed response, I was speaking with the two others maintainers and we're not at ease with adding custom metas in the project Cargo.toml. Part of this is that we're trying to minimize the global maintenance on the project and don't want having to maintain these metadatas in the foreseeable future with multiple projects adding their own meta.

Is there any chance that cargo-bininstall can install our binary without any Cargo.toml modifications? I'm under the impression that our binaries paths were rather common/standard but maybe I'm mistaken.

[swlynch99]

I suppose that's understandable.

The binary cache over at cargo-quickinstall should hopefully pick up new versions of hurl sooner or later. Once that happens then cargo-binstall will make use of that. I am not sure how long this will take, though.

As for the binary path, I think your tarball has a pretty standard folder layout too. However, it seems like the preferred way for anything that doesn't just have the binary in the package root is to use package metadata. I am not sure whether cargo-binstall would accept a change to the default paths.