Ben Brandt (Mar 01 2025 at 12:10): Ben Brandt (Mar 01 2025 at 12:10):Hey @Joel Dice and @Brett Cannon , the last meeting we mentioned it would be a good idea to standardize on which wasi-sdk we use for each series of Python versions, and that the wheels should use the same wasi-sdk version.
The proposal as I understood it was to lock to whichever version of wasi-sdk was available at the first alpha release of cpython, is that correct?
If so, then based on this, we would use:
wasi-sdk v24 for 3.14 (which is what Brett is already using) since that was available at the first alpha release.
However, for 3.13 and 3.12 we would not be able to do this, as the lowest we can go is wasi-sdk v21 for dynamic library support, which technically was released after the 3.13 alpha. And Brett is using wasi-sdk 24 anyway for his builds.
We use v21 for 3.12 since that is what componentize-py is doing and is the minimum we can do.
We use v24 for 3.13 and 3.14 since that is what Brett is doing, and then follow the plan for new versions going forward.
I think as long as we document the current decisions and what the plan is for this fall when 3.15.0a1 gets released, we should be ok.
I can rebuild the wheels based on whatever we decide.
Also, if there is a better way to tag the wheels with this information, let me know.
Ben Brandt (Mar 01 2025 at 13:01):Hmm to complicate things more: If I build pydantic with wasi-sdk 24, I get this error:
= note: wasm-ld: error: Invalid attribute group entry (Producer: 'LLVM19.1.7-rust-1.85.0-stable' Reader: 'LLVM 18.1.2-wasi-sdk')
So, we may also need to pin other things like Rust versions as well
Joel Dice (Mar 03 2025 at 14:41):The proposal as I understood it was to lock to whichever version of wasi-sdk was available at the first alpha release of cpython, is that correct?
That's my understanding, too, but I think we can decide for ourselves what to do for existing CPython releases (e.g. 3.12 and 3.13) since they went alpha before that proposal existed.
= note: wasm-ld: error: Invalid attribute group entry (Producer: 'LLVM19.1.7-rust-1.85.0-stable' Reader: 'LLVM 18.1.2-wasi-sdk')
You might need to link using the version of wasm-ld that ships with Rust's wasm32-wasip2 target instead of WASI-SDK's version (e.g. $HOME/.rustup/toolchains/stable-aarch64-unknown-linux-gnu/lib/rustlib/aarch64-unknown-linux-gnu/bin/gcc-ld/wasm-ld on my machine)
Brett Cannon (Mar 03 2025 at 23:12):Don't read too much into what I use to do my builds for 3.13. Sometimes I use a different version just to see if it will work without changes.
Brett Cannon (Mar 03 2025 at 23:13):And nothing is written down on the Python side, so we can do whatever we want. When we are ready to make it official it will get written down for every version so people don't have to guess.
Brett Cannon (Mar 03 2025 at 23:14):I.e. we can use WASI-SDK 24 if we want for 3.13. We can also be more specific about the wasi-libc version and mention what versions of the WASI-SDK shipped with that version (assuming WASI SDK doesn't influence anything we care about).
Ralph (Mar 04 2025 at 11:18):unduly flexible and forward looking. stop that.
Ben Brandt (Mar 05 2025 at 09:56):@Brett Cannon fair point. So the main thing we care about is wasi-libc.. however looking at it's versioning, it is tied to wasi-sdk anyway: https://github.com/WebAssembly/wasi-libc/tags
@Joel Dice thanks for the tip. I'll see if I can sort out finding the linker from the rust side
Ben Brandt (Mar 05 2025 at 10:08):@Joel Dice ok I realized in my pydantic script I was overriding the linker with the one from wasi-sdk. If I remove this, everything is happy again :+1:
Ben Brandt (Mar 05 2025 at 10:09):The final question for me is: do we go with wasi-sdk 24 or 25?
It seems that 24 is the safe option since Brett has done the most testing for that one?
Brett Cannon (Mar 05 2025 at 18:11):Ben Brandt said:
It seems that 24 is the safe option since Brett has done the most testing for that one?
It's definitely the easiest solution for me. :grinning_face_with_smiling_eyes:
Ben Brandt (Mar 05 2025 at 20:43):Sounds good :)
@Joel Dice I assume we might need to revisit once wasip3 lands in case you want to try this out in componentize-py?
@Brett Cannon if we had the wasi-sdk version + wasip1/2/3 in the platform part of the wheel tag would this help? We could potentially build against multiple setups?
Ben Brandt (Mar 05 2025 at 20:43):Forgive my naivety about build toolchains if this seems like a ridiculous question :D
Joel Dice (Mar 05 2025 at 20:48):@Joel Dice I assume we might need to revisit once wasip3 lands in case you want to try this out in componentize-py?
Given that WASIp3 will be a superset of WASIp2, I should be able to add decent WASIp3 support to componentize-py before wasi-sdk and wasi-libc support it at all. I.e. all the POSIX-y stuff will still use WASIp2, but you'll also be able to use WASIp3 features by using bindings generated from the WIT files directly.
In any case, don't worry about WASIp3 as far as this discussion goes.
Ben Brandt (Mar 05 2025 at 20:49):Ok sounds good 👍🏻
Brett Cannon (Mar 06 2025 at 20:40):We had discussed whether we would need to include the worlds used. And I don't know if we would want to consider it part of the platform or ABI part of the wheel file name.
Ben Brandt (Mar 06 2025 at 20:42):ah you were referring to the worlds. For some reason I thought you were referring to the wasi-libc version. Happy to defer to your opinion on this one
Brett Cannon (Mar 17 2025 at 19:59):Ben Brandt said:
ah you were referring to the worlds. For some reason I thought you were referring to the wasi-libc version. Happy to defer to your opinion on this one
I'm talking about both at this point as I'm not sure what influences what compiler settings need to be set.
Last updated: Apr 21 2025 at 22:03 UTC