Joel Dice

Thanks for reporting this, @kyleconroy. This sort of a duplicate of #23, but with a twist: `wasmtime-py` can't currently handle composed components (i.e. components that contain subcomponents), which is what...

I just had a wild idea: we could optionally iterate over all known modules during pre-initialization and import them one by one (skipping any not currently supported like `ssl`). Not...

Yeah, that's not bad. You probably already know this, but for anyone else reading: you can also import third-party packages (e.g. NumPy) the same way.

BTW, `wasm-tools strip -a` can reduce the component size quite a bit if desired.

We should do this for the examples as well. Ideally, this would take the form of a script that can be run either locally or during CI.

Good catch. Glad you found a workaround, but we should also fix `componentize-py` so it generates valid bindings for any valid WIT world, and ideally without having to use `__future__`...

Update: we have a pretty good `CONTRIBUTING.md` now, but could still use the other items listed above.

Also, include the version if needed to disambiguate.

I can't think of a way to make the multi-world support reusable outside of `componentize-py` since it's pretty tightly coupled with how that tool represents worlds and binding generation internally,...

What `componentize-py` does is generate a separate Python module for each world separately rather than combine them into a single world and generate code for that. As described above, those...