instead of `detect_targets`, so that if `opts.targets` is
`None`, the future returned by `detect_targets` can be run
in parallel by using `tokio::spawn` with other async code
in `entry`, such as `fetch_crate_cratesio`.
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
and `download_tar_based_and_visit`.
By using these two items, we avoid any I/O altogether.
Everything happens in memory, thus there will be no i/o related errors
or cost.
This commit does not regress anything because
`helpers::load_manifest_path` calls `Manifest::from_path_with_metadata`,
which read in the whole `Cargo.toml` file at once.
Thus this commit would not cause any OOM when the the original code
would not.
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>
Using `rt.block_on`, the future returned by `entry` can only be run on
the main thread.
Buf if we use `tokio::spawn`, then it can be run on any thread.
Signed-off-by: Jiahao XU <Jiahao_XU@outlook.com>
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.
