Basically this PEP says that the WASI and WASI SDK version under testing once b1 is reached will be the version that will be supported for that version of Python for its lifetime.
If people think that’s a bad idea then please let me know! Otherwise this aligns with what I have discussed with folks in the Bytecode Alliance and the Python sub-group of the guest languages SIG.
I think this PEP is a good idea, especially given that the WASI SDK ABI is not forwards or backwards compatible!
Some thoughts as I’m reading through the draft:
Should we add any language about the procedure for handling critical issues in a pinned WASI SDK version after beta 1? I’m assuming we’d handle that as needed and without involving the SC, but I’m not sure if it’s worth explicitly addressing in the PEP or if we should leave it implicit.
There’s a note about WASI SDK 26 and 27 causing CPython to hang in the Notes section. Should this be moved up into Rationale? It seems to be a good example of why this PEP is important.
Similar to Savannah’s first point, what’s the support policy for WASI/WASI SDK?
There haven’t been any minor releases so far, but it sounds like it might be possible in the future and we could still take minor updates. But if a security fix is only made in a newer WASI and not to our pinned one, do we tell people they need to upgrade to a newer Python that has a fixed WASI?
Also, the rationale talks of WASI 0.2 and WASI 0.3.1, but then the support table only has WASI p1. And then the support notes mention skipping WASI 0.2 for 0.3. The WASI website explains:
To date, WASI has seen two milestone releases known as 0.1 and 0.2. (Sometimes you will see these referred to as Preview 1 and Preview 2, or P1 and P2).
Can we use consistent version names? Just x.y rather than Px?
We can, but I’ve never seen support roll backwards since WASI is tier 2 and so folks have to make it work on the CPython side to pass the test suite (and that’s usually turning something off for WASI). Basically I have traditionally either made CPython work or in the case of WASI SDK 26 and 27, skipped a version.
We can.
Seems reasonable!
WASI is a spec, so I don’t even know how to answer that one in that instance.
As for WASI SDK, they don’t support old versions.
Honestly, I think they are being engineers and hedging what they say. I personally don’t ever expect a minor release and they would probably just do a major release as it would break assumptions everyone makes about version numbers (e.g. the GitHub releases lack a minor version number in the tag).
I’ve never seen that happen as security stuff is handled at the host level (e.g. wasmtime), and not the Wasm compiler level. It’s really more about if some version was a problem for the general community that wasn’t for us and so the community wants us to change the WASI SDK version.
Sure. I did it the way I did because no one calls it “0.1” in the WASI community as it predates the WASI version nomenclature (it started with 0.2).
OK, thanks, that all sounds fine.
Fair enough, the other way would be fine too, or use both, with a brief explanatory note.
Updates based on feedback · brettcannon/peps@c14ccce · GitHub has the relevant updates based on the feedback! Hopefully that catches what you two were after.
Thanks! Looks good to me!
Thank you for writing up this PEP draft Brett, I think it looks really good!
re post-beta 1 changes, I think it should be acceptable to update the WASI-libc version post-beta 1 if needed, but I cannot imagine updating the WASI version itself unless something has gone horribly wrong. Should we disallow that?
Also, I think listing the changes in the PEP is fine, but I expect we will want to communicate similar platform information for Emscripten (which is also ABI/platform locked) and pre-built CPython ( I expect we will be specifying a minimum libc). Perhaps this information would better fit to be put in PEP 11 notes section? Or the CPython documentation? I think having a single location for this information would be nice to have.