which pools the connection to the same site (github.com).
This commit also sets `USER_AGENT` so that quickinstall
can reuse it.
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
to improve efficiency by avoiding disk io (except for `PkgFmt::Zip`
and `PkgFmt::Bin`) and run the compresser in parallel to the downloader.
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
This from feedback in #19:
> wrt. bin-dir and bin-path, this appears to be a typo / should all be called bin-dir
This is only a readme fix afaict, I changed all occurences of `bin-path` in there to `bin-dir`.
> wrt. format, those are actually two (unfortunately named) different concepts, the first
refers to the archive format (eg. .tgz), the second to the binary format (which needs a .exe
appended for windows).
This introduces two new substitutions:
- `binary-ext` is the old "`format` in `bin-dir`"
- `archive-format` is the old "`format` in `pkg-url`"
Contents are unchanged: `binary-ext` includes the dot, `archive-format` doesn't. That
makes it easy to upgrade and also personally I slightly prefer it that way.
The old contextual `format` is still available, "soft deprecated": it will be accepted silently
so everything will work, but all documentation will use the new syntax. In the future we
could move to a "hard deprecated" model where installing a package that uses `format`
will warn the user / tell them to report that to the maintainer. I don't think we'll ever really
be able to remove it but that should be good enough.
A cool new feature is that `binary-ext` is now usable in `pkg-url`, which will be useful for raw binary downloads:
```toml
pkg_url = "{ repo }/releases/download/v{ version }/{ name }-v{ version }-{ target }{ binary-ext }"
```
I've also added a bunch of tests to GhCrateMeta around the templating for `pkg-url`.
See this issue: https://github.com/alsuren/cargo-quickinstall/issues/27
Quick Install is a hosted repo of built crates, essentially. The approach I've taken here is
a list of strategies:
1. First, we check the crate meta or default and build the URL to the repo. Once we have
that, we perform a `HEAD` request to the URL to see if it's available.
2. If it's not, we build the URL to the quickinstall repo, and perform a `HEAD` to there.
As soon as we've got a hit, we use that. I've built it so it's extensible with more strategies.
This could be useful for #4.
This also adds a prompt before downloading from third-party sources, and logs a short
name for a source, which is easier to glance than a full URL, and includes a quick refactor
of the install/link machinery.
