Installing from source via cargo install takes quite some time. It would be good if cargo binstall would be available by default and would not have to be installed manually. This way many CLIs would just need to say: To install do cargo binstall <my_package_cli> and seconds later the user would have the new cli / tool.
1 Like
cargo binstall installs from a source not under the control of the Rust project, so I think it is unlikely that we will start shipping cargo binstall with Rust.
5 Likes
It would be amazing if we could upload binary releases to crates.io, just like they can be uploaded to Github. That way, cargo-binstall could install from a crates.io url, rather than downloading from Github releases.
Cargo-binstall is a pragmatic tool; it currently downloads from Github because today that's where people upload built binaries.
It would be really nice if Cargo could install precompiled binaries.
It requires more than just bundling the binstall command: crates.io would have to run build infrastructure for compiling the binaries. There's already something for docs.rs, so maybe it's not too far fetched to build binaries too.
1 Like
Compiling docs isn't the same as compiling binaries though. There'd be questions about reproducibility, native dependencies, rebuilding for fixes in dependencies, and all the other things package managers have to deal with. And once you have all that then I suspect the next step would be the desire to ship larger artifacts, binaries that include assets...
2 Likes
Also, what features to build with, how to handle whether to respect local config (or what config the server builds with), etc.
I would see something like this as a cache for cargo install, so we'd also need --locked to be the default to have any semblance of caching but that needs a champion to drive.
On the other hand, if we get a cross-project cache and then add remote backends to it, projects could provide cached builds you opt-in to.
What's the problem with having the crate author upload binaries themselves? This is the status quo in Github releases and also releases published in a project's website.
I think that having the Rust Foundation foot this bill of compiling all and every binary project in the ecosystem is a big ask, and kind of orthogonal to upstreaming cargo-binstall.
Honestly it's baffling that --locked isn't the default. Multiple projects recommend installing their binaries with --locked and I've not seen any project that thinks it's desirable to have their lockfile ignored by default, with no warning.
1 Like
The crate author might upload malicious binaries that don't match the source code. This would likely be considerably harder to detect than uploading malicious source would be (although both are genuine risks, one would be easier to mitigate than the other).
5 Likes
Yes, this is pretty much the exact framework used in the XZ attack: uploaded artifacts are not git archive output, but instead processed by autoconf where you have to trust the process was done "properly" (note that there is no formal definition for "proper" without reproducible builds).
1 Like
Julia has some related infrastructure which might be helpful for inspiration, though not sure if we want or should copy it. Iirc it's especially popular for projects that wrap c libraries, since they can be compiled together in the builder: GitHub - JuliaPackaging/Yggdrasil: Collection of builder repositories for BinaryBuilder.jl
While I might not have come to the same decision (hard to say), I can understand preferring people getting patches immediately, rather than requiring a bin author to re-release, considering the state of the Rust and the wider programming ecosystem at the time, and general concerns of security.
However, to transition to --locked by default is not a free change and someone is needed to lead the requirements and design effort.