Develop bindings for WASI versions in parallel#118
Develop bindings for WASI versions in parallel#118alexcrichton merged 8 commits intobytecodealliance:mainfrom
Conversation
This commit is a reorganization of this crate to develop the
WASIp{1,2,3} crate bindings in parallel with each other in separate
crates. Historically the WASIp1 support ceased with the publication of
0.12.0 of the `wasi` crate which was the first release generated by
`wit-bindgen` suitable for use with WASIp2. The rough idea was to do the
same with WASIp3 at some point, but today it was realized that this
probably won't work.
Specifically the version number of the `wasi` crate right now is tied to
not only the WASI API version that's being bound but addition to the
`wit-bindgen` that is generating bindings. If either one updates in a
breaking way then the crate number here needs to be bumped. This means
that if we want to develop both WASIp2 and WASIp3 at the same time we'd
have to somehow reserve a space of future version numbers for the WASIp2
track which would be a bit awkward. Additionally it's a bit awkward to
have non-`main` development of WASIp2, a supported target, when WASIp3
wants to be added.
This new crate organization is intended to solve this concerns and looks
like so:
* Each version of WASI now has its own crate. For example there's now a
`wasip1` crate and a `wasip2` crate. Eventually there will be a
`wasip3` crate.
* A version-specific WASI crate is developed on `main` of this
repository and gets CI run, auto-generated bindings verified, etc.
Versions will be published as necessary for each version of each crate.
* The `wasi` crate is now a small wrapper around the latest stable WASI
release available. Currently this is a stable reexport of the `wasip2`
crate.
Various bits of README documentation have all been updated to reflect
this new structure. The intention is that in the near-ish future a
`wasip3` crate will be added which will contain auto-generated bindings
for WASIp3 and its upcoming snapshots. This new `wasip3` crate would not
be integrated into the `wasi` crate and the `wasi` crate would continue
to reexport `wasip2`. In this manner we can develop `wasip3` more easily
alongside the `wasip2` crate.
|
Ok should be good to go now. I plan on next adapting #111 to this structure to get WASIp3 bindings bootstrapped. |
|
Oh, I should also clarify, I've started wasip1/wasip2 crates at the 1.0.0 version track. They'd bump up naturally from there with any changes necessary. I plan on keeping |
pchickey
left a comment
pchickey
left a comment
There was a problem hiding this comment.
I think we should set something in the authors field, "Bytecode Alliance Contributors" I guess? Otherwise lgtm
| [package] | ||
| name = "wasi" | ||
| version = "0.14.4+wasi-0.2.4" | ||
| authors = ["The Cranelift Project Developers"] |
There was a problem hiding this comment.
"Bytecode Alliance"? "Alex Crichton"?
There was a problem hiding this comment.
Oh nowadays Cargo/crates.io basically ignore this field and it's not even generated by default, and AFAIK the recommendation is to remove it so I went ahead and cleaned it up here
|
Would be nice to use the new wasip1 crate in libstd. That would allow getting rid of the wasi exception for a dependency lint at https://github.com/rust-lang/rust/blob/66428d92bec337ed4785d695d0127276a482278c/src/tools/tidy/src/deps.rs#L863-L866 |
|
Agreed! I was planning on getting around to that after rust-lang/rust#147572 |
3 participants
This commit is a reorganization of this crate to develop the WASIp{1,2,3} crate bindings in parallel with each other in separate crates. Historically the WASIp1 support ceased with the publication of 0.12.0 of the
wasicrate which was the first release generated bywit-bindgensuitable for use with WASIp2. The rough idea was to do the same with WASIp3 at some point, but today it was realized that this probably won't work.Specifically the version number of the
wasicrate right now is tied to not only the WASI API version that's being bound but addition to thewit-bindgenthat is generating bindings. If either one updates in a breaking way then the crate number here needs to be bumped. This means that if we want to develop both WASIp2 and WASIp3 at the same time we'd have to somehow reserve a space of future version numbers for the WASIp2 track which would be a bit awkward. Additionally it's a bit awkward to have non-maindevelopment of WASIp2, a supported target, when WASIp3 wants to be added.This new crate organization is intended to solve this concerns and looks like so:
wasip1crate and awasip2crate. Eventually there will be awasip3crate.mainof this repository and gets CI run, auto-generated bindings verified, etc. Versions will be published as necessary for each version of each crate.wasicrate is now a small wrapper around the latest stable WASI release available. Currently this is a stable reexport of thewasip2crate.Various bits of README documentation have all been updated to reflect this new structure. The intention is that in the near-ish future a
wasip3crate will be added which will contain auto-generated bindings for WASIp3 and its upcoming snapshots. This newwasip3crate would not be integrated into thewasicrate and thewasicrate would continue to reexportwasip2. In this manner we can developwasip3more easily alongside thewasip2crate.Closes #117 (figured I'd throw this in)