Please support `cargo install` from source even if precompiled binary exists
Closed this issue · 3 comments
I was very surprised when running cargo install cargo-wasi that it seems to have installed a precompiled binary rather than installing from source.
I realize that cargo install does not have support for installing precompiled binaries, and I realize that you're trying to optimize for people running cargo install cargo-wasi so they don't have to wait for cargo-wasi's dependencies to compile. I'd also like to take a moment to say that this is a very impressive hack. :)
However, manually implementing support for precompiled binaries in this way has several surprising side effects:
- There's no clear indication that this is happening, other than noticing a mention of
cargo-wasi-exe-x86_64-unknown-linux-musland realizing what that implied. - There's no obvious way to avoid this and install from source. (Any mechanism integrated into
cargowould be user-controllable, such as through an explicit option toinstallor a separate command.) - This installs a binary that may not match the user's desired configuration (e.g. dynamically linking against system libraries, using glibc rather than musl). (Note that I was installing for a glibc target.)
- The update checking will not be desirable for packaged versions of
cargo-wasi, and would require patching to disable in that case. - As far as I can tell,
cargo-wasi-srcfrom crates.io doesn't build; it errors out with:error[E0433]: failed to resolve: use of undeclared type or module cargo_wasi. - cargo-wasi seems to also assume a prebuilt binary version of wasm-opt as well, rather than using a system version. (I managed to find where that's documented in the manual, but that's another behavior that wouldn't be desired for integration into a distribution and would need working around.)
Could you please provide a means of using cargo install to install cargo-wasi from source and not use precompiled binaries?
I would personally prefer if cargo install cargo-wasi-bin installed a precompiled binary that uses precompiled binaries, and cargo install cargo-wasi installed from source and expected system binaries. But I could also live with flipping those around so that cargo install cargo-wasi-src installed from source and expected system binaries, or if passing a feature flag disabled the use of precompiled binaries, as long as that was clearly documented; it wouldn't be my preference, but I can imagine that others might prefer that.
Thanks for the report! It was always intended that cargo install cargo-wasi-src worked as "install from source" but looks like it had a typo and broke along the way in developing this, sorry about that! I've now fixed that now.
Otherwise this should be working now I believe. If there are issues with the wrong platform that can be handled as they arise (I don't think that is configured to happen right now though). I'll push up some documentation about installing from source to make sure it's in the reference though.
I've opened #25 to track the a feature which will disable the update check if this is packaged elsewhere.
cargo-wasi seems to also assume a prebuilt binary version of wasm-opt as well, rather than using a system version.
This is an explicit decision currently because of the instability we've experience from wasm-opt historically, but this is something that we can of course add a build-time configuration feature for if this is packaged elsewhere though!
@alexcrichton Thank you very much for the fix! The documentation you provided helps, and I can try to propagate a similar note to other guides/tutorials that suggest installing cargo-wasi.
I've opened #25 to track the a feature which will disable the update check if this is packaged elsewhere.
That would indeed help, thank you. As a thought, would you consider making the update check a disabled-by-default feature, and then setting that feature when building the prebuilt binaries? If someone takes the time and trouble to build cargo-wasi-src from source, they likely want to continue doing so.
This is an explicit decision currently because of the instability we've experience from wasm-opt historically, but this is something that we can of course add a build-time configuration feature for if this is packaged elsewhere though!
I absolutely appreciate that, and I wouldn't want you to compromise the user experience (or generate more support issues) for users who install the prepackaged binaries. The case I'm thinking of would be users who have already installed a stable packaged binary version of wasm-opt from their distribution, and want to make sure cargo-wasi uses that version. (Distribution packagers of cargo-wasi would want the same thing, and would declare a dependency from their cargo-wasi package to the package providing wasm-opt.)
I'd very much like to have build-time configuration for this. Would it make sense to tie this to the bundling of the requisite binary alongside the prebuilt cargo-wasi binary? That would mean that the prebuilt binary would have its prebuilt wasm-opt, and users who build from source would need wasm-opt on their PATH (unless they also use the same mechanism to bundle a wasm-opt themselves). Does that seem reasonable to you?
Thanks again for cargo-wasi! I really appreciate how much work you're putting in to provide not just capabilities but usability to help people work with WebAssembly and WASI!