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
wasi
crate don't rely on thehttp
world as I mentioned in https://github.com/bytecodealliance/wasmtime/pull/8928#issuecomment-2221849156.cc @alexcrichton
iawia002 requested alexcrichton for a review on PR #8939.
iawia002 requested wasmtime-core-reviewers for a review on PR #8939.
iawia002 updated PR #8939.
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/imports
for all the relevant WIT packages. For exports there would then be a singlegenerate!
-per-world supported which useswith
to 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.
iawia002 commented on PR #8939:
Yes, that makes sense. However, to support this model, we need the
test-programs
crate to have WIT definition files of all the WASI APIs. For example,wasi-runtime-config
is 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-cli
andwasi-runtime-config
in 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-programs
can all directly use the WIT files from this directory. This would also simplify thevendor-wit.sh
script.Hope I didn't misunderstand your point.
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-wasi
has all the WIT files forwasmtime-wasi-http
despite 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
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.
iawia002 requested wasmtime-default-reviewers for a review on PR #8939.
iawia002 updated PR #8939.
iawia002 requested alexcrichton for a review on PR #8939.
Last updated: Dec 23 2024 at 12:05 UTC