Christoph Brewing (Nov 28 2023 at 15:36): Christoph Brewing (Nov 28 2023 at 15:36):After having updated cargo-component-bindings and wasmtime, I have difficulties to run my component in Python:
I build the component running cargo component build --release --target wasm32-unknown-unknown with dependencies cargo-component-bindings = "0.5.0" and generate Python bindings running python -m wasmtime.bindgen the-component.wasm --out-dir the-bindings under wasmtime==15.0.0.
The error message says
wasmtime._error.WasmtimeError: failed to parse WebAssembly module
Caused by:
Invalid input WebAssembly code at offset 0: unknown binary version and encoding combination: 0xd and 0x1, note: encoded as a component but the WebAssembly component model feature is not enabled - enable the feature to allow component validation
Even though the error message is pretty clear, I am not sure where to enable "the feature".
In the past, I could then run my component smoothly in Python.
Is used versioning supposed to be compatible?
Thank you very much for any hint.
Pat Hickey (Nov 28 2023 at 15:52):wasmtime-py is using the c api to wasmtime, which is not built with the component-model feature enabled
Pat Hickey (Nov 28 2023 at 15:54):which is mostly because the c api doesnt yet have any of the component interfaces of wasmtime available - they havent been written yet. im not sure if someone was working on it or not.
Alex Crichton (Nov 28 2023 at 17:03):hm although this is generating bindings rather than running the component so that in theory should work, @Christoph Brewing would you be able to make a small repo showcasing a repro?
Christoph Brewing (Nov 28 2023 at 19:28):@Alex Crichton Good idea. I will try to repeat the problem with an isolated toy example. Give time me until tomorrow.
Christoph Brewing (Nov 29 2023 at 08:38):@Alex Crichton
I was able to isolate the problem without a standalone example:
When crafting the Python bindings, python -m wasmtime.bindgen the-component.wasm --out-dir the-bindings, among other things, a file is generated which closely mimics my component. The name of the file usually is root.core0.wasm.
Executing the Python host with this file works. Executing the Python host based on the original component fails. I also observe that the sizes of both files slightly differ. My original component is 27.755 KB of size where root.core0.wasm is 27.751 KB of size.
My original assumption was that the Python bindings generator merely copies and rename my component. Yet, it seems to modify it. The anticipated use-case is to have many wasm components (all sharing the same interface) which can be instantiated based on a respective configuration.
Is that a stable behavior? I mean, will it be this way for long? Does it even have to be that way? I am sure that, in the past, I just called the Python bindings with the (original) component.
Alex Crichton (Nov 29 2023 at 16:19):Ah ok you're running into expected behavior for the Python generator right now. The input component has a different binary format than the root.N.wasm file which is a core wasm module. The root.N.wasm was originally present inside of the source component and takes up the majority of the space as you've seen, but they're not the same and aren't intended to be the same.
At this time Python bindings only work with the single component that was provided as input. You can't, at runtime, supply a component without rerunning bindinge. Supporting that style of embedding would require implementing support for the component model in Wasmtime's C API and then binding that in Python.
Christoph Brewing (Nov 30 2023 at 11:14):good to know, thanks! Is that on the general path, I mean, implementing support for the component model in Wasmtime's C API and the corresponding Python bindings?
Joel Dice (Nov 30 2023 at 14:58):I'd love to see someone update wasmtime-py to support resources and arbitrarily-composed components, which would presumably require extending Wasmtime's C API (although using the Rust API via Py03 might also be an option). I'm not volunteering for it, though, and I don't think anyone else has, either.
Alex Crichton (Nov 30 2023 at 15:50):Yes integrating the component model with the C API is desired and there was discussion a day or so about it here
Last updated: Nov 22 2024 at 16:03 UTC