Wasmtime GitHub notifications bot (Jul 11 2024 at 07:07): Wasmtime GitHub notifications bot (Jul 11 2024 at 07:07):iawia002 opened PR #8939 from iawia002:test-mod to bytecodealliance:main:
This patch reorganizes the modules generated by wit, merging all wit-generated wasi content into a single mod like wasi-rs.
<img width="395" alt="Screenshot 2024-07-11 at 14 54 08" src="https://github.com/bytecodealliance/wasmtime/assets/9134003/503babf5-0c88-4ea7-9591-2a2bbc3e2e4d">
This will facilitate the addition of new WASI APIs like wasi-runtime-config and make the import paths more straightforward (for the wasi-runtime-config case, it will be
test_programs::wasi::config).And I believe this could make the wit dependencies of the
wasicrate don't rely on thehttpworld as I mentioned in https://github.com/bytecodealliance/wasmtime/pull/8928#issuecomment-2221849156.cc @alexcrichton
Wasmtime GitHub notifications bot (Jul 11 2024 at 07:07):iawia002 requested alexcrichton for a review on PR #8939.
Wasmtime GitHub notifications bot (Jul 11 2024 at 07:07):iawia002 requested wasmtime-core-reviewers for a review on PR #8939.
Wasmtime GitHub notifications bot (Jul 11 2024 at 07:57):iawia002 updated PR #8939.
Wasmtime GitHub notifications bot (Jul 11 2024 at 14:31):alexcrichton submitted PR review:
If we go this route I'd prefer to restructure things a little bit to make it a bit more maintainable over time. Of bindings to generate they basically fall into the categories of "what to import" and "what to export" where imports are a union of everything supported and exports are separated per-world.
For imports I think it would be best to use the inline WIT syntax that
generate!supports and toinclude wasi:cli/importsfor all the relevant WIT packages. For exports there would then be a singlegenerate!-per-world supported which useswithto point all dependencies to the main "soup of imports".Does that make sense? It would avoid the need to weave everything back together in Rust code and would enable keeping things separate.
Wasmtime GitHub notifications bot (Jul 11 2024 at 16:08):iawia002 commented on PR #8939:
Yes, that makes sense. However, to support this model, we need the
test-programscrate to have WIT definition files of all the WASI APIs. For example,wasi-runtime-configis a very simple and standalone API, it doesn't depend on any other WASI APIs, nor is it depended upon by others. If we want to include bothwasi-cliandwasi-runtime-configin a singlegenerate!, their WIT files need to be in the same directory. I'm wondering if we could place the WIT files for all APIs in a separate directory, so thatwasi,wasi-http, andtest-programscan all directly use the WIT files from this directory. This would also simplify thevendor-wit.shscript.Hope I didn't misunderstand your point.
Wasmtime GitHub notifications bot (Jul 11 2024 at 18:07):alexcrichton commented on PR #8939:
The solution we've had for that is to have copies of WIT files in multiple locations. It's not a great solution but it's why
wasmtime-wasihas all the WIT files forwasmtime-wasi-httpdespite not using them. Unfortunately we can't move everything into a single directory easily because when we publish these crates to crates.io that directory needs to be included so the crates can be built when downloaded from crates.io
Wasmtime GitHub notifications bot (Jul 12 2024 at 00:36):iawia002 commented on PR #8939:
because when we publish these crates to crates.io that directory needs to be included so the crates can be built when downloaded from crates.io
Oh right, since test programs don't need to be published to crates.io, I forgot to consider that. I'll make an update soon.
Wasmtime GitHub notifications bot (Jul 12 2024 at 01:33):iawia002 requested wasmtime-default-reviewers for a review on PR #8939.
Wasmtime GitHub notifications bot (Jul 12 2024 at 01:33):iawia002 updated PR #8939.
Wasmtime GitHub notifications bot (Jul 12 2024 at 01:33):iawia002 requested alexcrichton for a review on PR #8939.
Last updated: Dec 13 2025 at 19:03 UTC