Alex Crichton (Nov 12 2025 at 17:22): Alex Crichton (Nov 12 2025 at 17:22):In https://github.com/WebAssembly/wasi-libc/pull/667 I'm adding a new job to wasi-libc's CI which builds Python with the in-tree copy of libc. The intent is to help increase the test coverage for wasi-libc, but I also know very little of Python and how its build system/etc are all set up. If someone with a more Python-trained eye would like to give thoughts/opinions it'd be most welcome!
Alex Crichton (Nov 12 2025 at 17:33):For example, if there's a better way to build, better way to patch, better source of truth, more tests to run, etc, I'd love to hear!
Till Schneidereit (Nov 12 2025 at 18:17):@Brett Cannon I also pinged you on the PR, but now just saw that Alex posted about this here
Brett Cannon (Nov 12 2025 at 18:58):I just left comments, but the PR was already merged (none of the comments are critical, but I did ask if the patches being applied should be upstreamed).
Alex Crichton (Nov 12 2025 at 19:10):Brett got a preference if I respond on github or here? Happy to do either but trying to avoid both heh
Alex Crichton (Nov 12 2025 at 21:53):(responded online)
Brett Cannon (Nov 12 2025 at 22:54):Alex Crichton said:
Brett got a preference if I respond on github or here? Happy to do either but trying to avoid both heh
Nope, whatever you prefer.
Brett Cannon (Nov 12 2025 at 23:02):(And I already replied to your comments on GitHub, so I guess over there!)
Alex Crichton (Nov 13 2025 at 23:46):Ok @Brett Cannon a few questions for you:
Is updating to wasi-sdk-28 in Python's CI as simple as a PR? If I were to do that I think it's all checked in CI, right? Is there any other sort of process that I should be aware of? For example if I were to subsequently release wasi-sdk-29 which will likely happen soon, is there enough process that I should avoid doing this or is it lightweight enough that one PR to upgrade to 28, then a subsequent one later for 29, would be ok? To give you a sense of scale these are the changes necessary to get tests working. I'd more thoroughly investigate the max-stack-size thing before proposing another doubling.
Have you and/or Python folks thought much about WASIp2 support? Joel and I have been running Python tests with WASIp2 by "hacking around it" and passing CFLAGS="--target wasm32-wasip2". As far as we can tell this is really all that's needed as everything Python needs goes exclusively through wasi-libc so it's just a matter of compiler flags (e.g. wasi-sdk stays the same). The artifact of the final *.wasm changes, however, from a core module to a component. Is this something that Python would be interested in, perhaps even just as a test in CI before it's official? Or something that's best left for a debate for another day?
WASIp2 is a leading question. I'd like to, in wasi-libc's CI, run the test suite of Python with sockets support. This requires the wasm32-wasip2 target as sockets don't work in wasm32-wasip1. That's fine and all, but the changes in Python to make the test suite pass are fairly large. I had to annotate a whole bunch of tests with "this needs threads to run" and on the tail end of some tests I had to add some checks for sys.platform == 'wasi' which didn't feel great. This is a large enough patch that I wouldn't want to carry this in wasi-libc and would prefer to effectively upstream directly, but I'm not sure how amenable upstream would be to this. My read of other tests is that sprinkling @threading_helper.requires_working_threading() around is probably fine, but checking for sys.platform is probably not fine. As I imagine you already sprinkled a bunch of annotations around though I'm curious to get your take on this as well and if you have thoughts
Brett Cannon (Nov 17 2025 at 19:23):Alex Crichton said:
Is updating to wasi-sdk-28 in Python's CI as simple as a PR?
Yep! https://opensource.snarky.ca/Python/WASI/Support+a+new+WASI+SDK+version is the "official" TODO list by hopefully the end of the year, but step 4 isn't ready yet and an external PR doesn't need to be draft (that's just for me to not accidentally merge too early). And any hand-wavy bits in that list is because I haven't tested the list out yet (it was written from memory).
Alex Crichton said:
If I were to do that I think it's all checked in CI, right?
Yes. I try to keep my life simple. :wink:
Alex Crichton said:
For example if I were to subsequently release wasi-sdk-29 which will likely happen soon, is there enough process that I should avoid doing this or is it lightweight enough that one PR to upgrade to 28, then a subsequent one later for 29, would be ok?
It's so lightweight I repurposed my "upgrade to WASI SDK 28" issue to say "29" as soon as I saw you cut a new release. :grinning_face_with_smiling_eyes:
Alex Crichton said:
Have you and/or Python folks thought much about WASIp2 support?
I have personally, and I've talked about this with Joel for some time (don't worry about other core devs, the ones that care talk to me, but otherwise I'm still trying to convince folks that WASI isn't just some niche thing that's going to die off in a couple of years or stay AIX-level niche).
Alex Crichton said:
Is this something that Python would be interested in, perhaps even just as a test in CI before it's official?
It can't go in without it being official, and that's not going to happen until WASI 0.3.1 and I get threads as I'm not comfortable claiming socket support without test_socket passing (same thing I brought up at the Plumber's summit at MS a couple of years ago when we met in person).
Alex Crichton said:
- That's fine and all, but the changes in Python to make the test suite pass are fairly large.
I've reviewed bigger PRs. :wink:
Alex Crichton said:
- I had to add some checks for
sys.platform == 'wasi'which didn't feel great.
Then I wouldn't look at https://github.com/python/cpython/blob/5d2eb98a91f2cd703d14f38c751ac7f52b2d7148/Lib/test/support/__init__.py#L584 which is where we hide that not "feel great" feeling behind a constant. :wink: Honestly the test suite is littered with "don't bother on WASI" markers along with other platform-specific stuff (search for "wasi" in that file to see other helpers we have for WASI and Emscripten, then search for all the uses of those helpers :sweat_smile:).
Alex Crichton said:
I'm not sure how amenable upstream would be to this.
In this case I'm "upstream" and I'm amenable as it's just adding appropriate annotations that are missing by accident.
Alex Crichton said:
- My read of other tests is that sprinkling
@threading_helper.requires_working_threading()around is probably fine, but checking forsys.platformis probably not fine.
Both are fine (as long as you use the right helper in . Welcome to trying to support a wide range of OSs in a large, wide-ranging code base that tickles every OSs quirks! :wink:
So I'm good with accepting a PR to add the appropriate annotations so you can test p2 in wasi-libc as long as I don't have to worry about p2 support in WASI until I can run test_socket appropriately.
Alex Crichton (Nov 17 2025 at 19:32):Nice, that all sounds pretty good. I'll try to make a PR for wasi-sdk-29 in the coming days.
For p2/annotations, I'm hesitant to land all these annotations in upstream python if nothing is testing them since they seem like it'd easily regress. I've got test_socket running locally insofar as everything requiring threads is auto-skipped, but are you saying that test_socket needs to pass fully, including threads, to support adding a new CI target?
Brett Cannon (Nov 18 2025 at 20:08):Alex Crichton said:
are you saying that
test_socketneeds to pass fully, including threads, to support adding a new CI target?
Yes because my worry is so much is skipped without threads that I don't feel comfortable saying sockets are supported otherwise.
Brett Cannon (Nov 19 2025 at 19:02):I just wanted to give a quick thanks to @Alex Crichton for getting CPython on to WASI SDK 29 and bearing with me as we tested out the latest flow for a version bump!
Last updated: Dec 06 2025 at 07:03 UTC