Conversation
pchickey
force-pushed
the
pch/use_wasip2_crate
branch
from
d122fec to
c664bd9
Compare
| pub use http::header::{InvalidHeaderName, InvalidHeaderValue}; | ||
| pub use http::method::InvalidMethod; | ||
| pub use wasi::http::types::{ErrorCode as WasiHttpErrorCode, HeaderError as WasiHttpHeaderError}; | ||
| pub use wasip2::http::types::{ErrorCode as WasiHttpErrorCode, HeaderError as WasiHttpHeaderError}; |
There was a problem hiding this comment.
Please consider using semantic versioning for your crate, i.e. v0.5.5 -> v0.6.0 instead of v0.5.6 when changing the public API in a non-backwards compatible way. Thanks!
There was a problem hiding this comment.
This should be backwards compatible, since the wasi crate is now a thin re-export of the wasip2 crate: https://docs.rs/wasi/latest/src/wasi/lib.rs.html#1-2.
If you're running into compatibility problems, please consider filing an issue with your Cargo lockfile attached.
There was a problem hiding this comment.
Don't get me wrong, this is not a big issue. Easy to fix on the consumer-side, just avoidable. I wouldn't want to file an issue because there's nothing much todo. Mostly an FYI
Yet, v0.5.5 -> v0.5.6
error[E0432]: unresolved import `wstd::wasi`
--> crates/wasm-runtime-guest/src/lib.rs:46:9
|
46 | pub use wstd::wasi;
| ^^^^^^^^^^ no `wasi` in the root
|
help: consider importing this module instead
|
46 - pub use wstd::wasi;
46 + pub use crate::wit::wasi;
|
|
That wasn't supposed to be part of the public api but we didn't document it explicitly enough. See #90 (comment) #91 |
4 participants
As of bytecodealliance/wasi-rs#118, the
wasicrate is just a facade to thewasip2crate. Instead of depending on the facade, usewasip2directly, in anticipation that we will one day soon usewasip3as well behind the appropriate cfg.