Change encoding of WIT definitions into Component Model types #248
Conversation
There was a problem hiding this comment.
All looks good to me, thanks for writing this up!
In terms of rolling this out an idea I'd have for a plan would be basically the same as #249 where both encoding formats are implemented for a short period of time. First with the old one as the default, then the new one as the default, then only the support for the new one.
|
@elliottt, @lukewagner, and I talked a bit about this new encoding scheme and have reached the conclusion that a proposed tweak would be to change export-of-instance-type to become export-of-instance. The rationale is not about the design per se but instead relates to bytecodealliance/wasm-tools#1253 where currently wasm-tools doesn't validate export-of-instance-type correctly when the type has resources inside of it. Moving to export-of-instance would sidestep the questions raised there and ideally buy more runway to figuring out how to correctly implement this in wams-tools. As an orthogonal point, though, @elliottt and I also realized that with this encoding scheme then an empty WIT package with no interfaces or worlds can't be encoded. Basically the package name and namespace is lost and there's nowhere to put it. Shall we perhaps consider empty packages invalid from a parser level in that case? |
|
Oh, and to your second point, that's a good point, and one I wrestled with too. Although it's a bit subtle, I think what we can say is that the point of the interface names in the encoding is not to name the package, but, rather, to name the definitions in a way that is later validated to be consistent with the externally-assigned name of the package at the point of publication. So, e.g., we could union two packages into a single component binary; the result wouldn't be publishable as a package (b/c the package-name-consistency validation would fail), but it would be useful as a single-file collection of "all the type info", which I think is useful for some of the future non-publishing workflows we talked about earlier. If we wanted, we could define a "package metadata" custom section that would include author, email, description, etc, and this might be a natural place for the package name to canonically reside. |
lukewagner
force-pushed
the
tweak-wit-packages
branch
from
23e2cc5
to
e60d8e4
Compare
This commit enables the new encoding for WIT packages in WebAssembly components described in WebAssembly/component-model#248 and originally implemented in bytecodealliance#1252. Support for the new encoding has been in a wasm-tools for a bit and it's also released with Wasmtime 14. This switch means that infrastructure will start being exposed to it by default now. Support for the old encoding remains to assist with interop as well. In a release or two support for creating the old encoding will be removed.
This commit enables the new encoding for WIT packages in WebAssembly components described in WebAssembly/component-model#248 and originally implemented in #1252. Support for the new encoding has been in a wasm-tools for a bit and it's also released with Wasmtime 14. This switch means that infrastructure will start being exposed to it by default now. Support for the old encoding remains to assist with interop as well. In a release or two support for creating the old encoding will be removed.
This PR tweaks the encoding of WIT definitions into component-level types as described in WIT.md. The primary motivation here is to avoid having a special kind of "WIT package" and rather to allow WIT definitions to just be normal (type) definitions inside normal components that can be exported and named like anything else. This allows more-unified registry tooling and also it allows a bit more flexibility for packages to contain both implementation and interface definitions.