Wasmtime GitHub notifications bot (Jun 08 2024 at 05:22): Wasmtime GitHub notifications bot (Jun 08 2024 at 05:22):juntyr opened issue #8759:
Feature
It would be great if wasi-preview1-component-adapter was published to crates.io, either directly, or using a wrapper crate that exposes the prebuilt (either before publishing or as part of this crate's build process) adapter WASM file. Note that if the crate is just published as-is, the latter can also be done by users themselves.
Benefit
I am building several WASM components in my crate. This is currently orchestrated by a build script, which builds the WASM module crates and then adapts them to components using the wit-component crate and the wasi-preview1-component-adapter WASM file. This adapter is currently downloaded in the build script from wasmtime's release page. A manual download like this is a quite unrusty approach and would fail inside a network-isolated build script. Being able to build the WASM adapter directly in my build graph would solve this problem.
Implementation
The https://crates.io/crates/wasi-preview1-component-adapter crate name has already been reserved, so starting with the next wasmtime release, the wasi-preview1-component-adapter crate could be published as-is to crates.io just like the other crates.
Alternatives
Publishing the pre-built WASM file, e.g. embedded in the source of a crate, would remove the complexity of building the WASM file from end-users and allow everyone to depend on exactly the same binary WASM file. However, it would require an extra wrapper crate.
Wasmtime GitHub notifications bot (Jun 10 2024 at 14:44):alexcrichton commented on issue #8759:
The adapters are unfortunately sort of nontrivial to build, for example these configuration settings are required. The build script also has checks to verify that the adapter is a valid adapter (e.g. no
datasections). It's possible to publish the crate as-is but I'd fear that it might not help your building situation. Is this a case where vendoring the binary could perhaps be done? That's probably the easiest way to depend on the adapter.
Wasmtime GitHub notifications bot (Jun 10 2024 at 14:59):juntyr commented on issue #8759:
Thank you for your reply @alexcrichton and for always taking the time to help me :)
I’d been aware of the complex build script but not yet of the config. If I would need to replicate those in my own workspace Cargo.toml, then I agree that that would defeat part of the advantage of integrating the adapter directly into my build.
At the moment, I have a build script which downloads the adapter from the releases page and then builds several other crates as WASM modules (and then turns them into components). Directly embedding the binary into my repo would work to solve the build isolation issue but would make maintenance a bit harder and my repo a bit more bloated. I think that would be ok temporarily.
What about the idea of creating a wrapper crate that exports the adapter as a byte string? The crate could be built just after the adapter in CI and then published to crates.io. That way tools that currently require the adapter to be downloaded could depend on this crate as well.
If that’s a possible path forward, I’d happily write up a PR for it.
Thanks again for your help!
Wasmtime GitHub notifications bot (Jun 10 2024 at 15:28):alexcrichton commented on issue #8759:
I do think something like that could work yeah. I'm not sure how best to architect it though. Publishing crates with generated files as part of the publish I've found historically is not an easy task unless all the generated files are additionally checked in to the repository. Basically Cargo doesn't provide an easy way to manage all this, so the other alternative is lots of CI logic to paper over it which can get quite hairy from a maintenance perspective.
Despite that though I can think of a few other possible consumers for a crates.io-based version of the compiled adapters, so it would indeed be really nice to have. The lowest-overhead solution is to probably check the adapters into the repository and check on CI that the adapters haven't changed. That has its own downsides of requiring a fixed toolchain but given that most developers aren't changing the adapter when contributing the Wasmtime it's not the end of the world.
Wasmtime GitHub notifications bot (Jun 18 2024 at 15:54):alexcrichton closed issue #8759:
Feature
It would be great if wasi-preview1-component-adapter was published to crates.io, either directly, or using a wrapper crate that exposes the prebuilt (either before publishing or as part of this crate's build process) adapter WASM file. Note that if the crate is just published as-is, the latter can also be done by users themselves.
Benefit
I am building several WASM components in my crate. This is currently orchestrated by a build script, which builds the WASM module crates and then adapts them to components using the wit-component crate and the wasi-preview1-component-adapter WASM file. This adapter is currently downloaded in the build script from wasmtime's release page. A manual download like this is a quite unrusty approach and would fail inside a network-isolated build script. Being able to build the WASM adapter directly in my build graph would solve this problem.
Implementation
The https://crates.io/crates/wasi-preview1-component-adapter crate name has already been reserved, so starting with the next wasmtime release, the wasi-preview1-component-adapter crate could be published as-is to crates.io just like the other crates.
Alternatives
Publishing the pre-built WASM file, e.g. embedded in the source of a crate, would remove the complexity of building the WASM file from end-users and allow everyone to depend on exactly the same binary WASM file. However, it would require an extra wrapper crate.
Last updated: Dec 23 2024 at 12:05 UTC