`cargo install` should download binaries from crate.io if a compatible dependency/feature-set is availible

[wy6688]

Problem

"Cargo install" should provide download binaries only from crate.io if availibale rather than build these binaries every time when calling cargo install. since the build process in local computer is very slow, especially when call "cargo install" when build a docker containers.

Proposed Solution

provide "cargo install --no-locall-build" or "cargo install --download_binaries_only"

Notes

No response

[wy6688]

Since the "cargo install" only installed tools used by local env, download these tools is lots of faster than build them locally.
In my docker enviroments, every time when I rebuild my dev container, over 99.99999% times is on "cargo install", over 20 minutes.

[epage]

An important first step in consideration is #7169 as we would effectively be locking in the lockfile otherwise.

We also have #5931 which would help some but not too much until the follow up idea of a remote cache support and then that could be a potential way of solving this problem.

There is also the question of what the role of cargo install should be. Personally, I don't think we should grow the scope to pull in more general purpose binary package distribution needs (e.g. #2729) and which inclines me to say we shouldn't have a special built built-in pre-built bin install system.

In terms of third-party efforts in this direction, see https://crates.io/crates/cargo-binstall

[wy6688]

Thank you so much for your fast reply and help.
The cargo-binstall do works perfect for my case, greatly reduced my dev container rebuild time.
It maybe best integrate or merge this feature as build-in, so as avoid to compile and build cargo-binstall tools also.

[epage]

We discussed this further in today's Cargo team meeting.

While some ecosystems have maintainer-built binaries, that doesn't quite work for Rust

• The number of inputs for a build combination are large and we're have to invent a system to track all of this
• Chain of trust for the binaries

For some of those ecosystems, its more acceptable out of necessity because of how few of their users have a toolchain for building native packages.

cargo-binstall is something that exists in the Rust ecosystem today but it doesn't align with cargo install and having a parallel system built-in isn't ideal. It does not align because

• It takes on assumptions of hosting services (even if it can be customized)
• It doesn't handle the users specified build inputs

This is where the per user caching comes in. That initially would be local only and intermediate-artifacts only. If/when we expand to remote caches, we could also add support for final artifacts. crates.io could then have a build system, like docs.rs, with suggested build configurations specified in Cargo.toml. They would have to define a cache reclamation policy. This would be used to populate the cache. If there is a cache hit on the final artifact, great! if there is a cache miss on the final artifact, there might still be cache hits on the intermediate artifacts.

So this is blocked on

• "cargo install" apparently ignores "Cargo.lock" as opposed to "cargo build" #7169 (to reduce cache misses)
• Per-user compiled artifact cache #5931
• Remote caching built on top of Per-user compiled artifact cache #5931

This issue would then be tracking

• Final artifact support
• Registries reporting their remote cache location
• Working with crates.io for their implementation of the remote cache

Be warned that this is a many years effort. As such, we had considered closing this as postponed due to how far out this is (and it being unknown how much might change before then) but we are keeping this for now as a central focus for these discussions.