Stream: SIG-Guest-Languages

Topic: Testing Python in wasi-libc's CI

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:

1. 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.

2. 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?

3. 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 for sys.platform is 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_socket needs 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!

Alex Crichton (Jul 22 2026 at 15:25):

Reviving an older thread for this, but @Brett Cannon I wanted to give you a heads up about the upcoming possibility of a wasip3 target with threads being supported in Python. I've now got Python's test suite passing in wasi-libc's CI with threads/sockets/etc all enabled. There's notes in that PR that changes to Python are still needed (and the patch has grown), but that's at least a starting point.

For wasi-libc this was quite useful IMO to flesh out API behavior, functionality, and breadth, so no matter what I'd like to keep this in wasi-libc's CI. For Python though I don't plan on actively pursuing this upstream myself, but I'd be happy to help out with anything if you're curious to look into it.

Joel Dice (Jul 22 2026 at 15:29):

On a related note: we can't use threads in componentize-py just yet due to https://github.com/llvm/llvm-project/issues/188077, but Alex and I are planning to bring that up with some LLVM maintainers at a meeting on Monday and hopefully make some progress.

Brett Cannon (Jul 22 2026 at 16:58):

Alex Crichton said:

There's notes in that PR that changes to Python are still needed (and the patch has grown), but that's at least a starting point.

Thanks so much! It definitely gives me a place to work from to try and turn support on when I have the time.

Alex Crichton said:

For Python though I don't plan on actively pursuing this upstream myself, but I'd be happy to help out with anything if you're curious to look into it.

Thanks! Probably my first step is exposing WASI details in the sys module and getting general WASI 0.3 support turned on for CPython 3.16.

Joel Dice said:

we can't use threads in componentize-py just yet

I assume that's specific to componentize-py and not CPython in general?

Joel Dice (Jul 22 2026 at 17:06):

Brett Cannon said:

I assume that's specific to componentize-py and not CPython in general?

It's specific to building libpython3.xx.so for wasm32-wasip3 with threading support. python.wasm (i.e. an "executable" wasm rather than a "library" wasm) should handle threading just fine.

Alex Crichton (Jul 22 2026 at 17:07):

For sys module details I sketched that out here what it might look like if you're looking for inspiration, feel free to take that or leave it though!

Joel Dice (Jul 23 2026 at 00:39):

Correction: the issue I linked to above was about exception handling in shared libraries, not threading in shared libraries. They're both broken, but we're closer to getting the latter working.

Brett Cannon (Jul 23 2026 at 23:00):

Alex Crichton said:

For sys module details I sketched that out here what it might look like if you're looking for inspiration, feel free to take that or leave it though!

I don't think I would bother with the SDK major version as it's easy enough to split a string on . in Python, otherwise I would keep the major version and drop the full version, but that feels bad for leaving info on the table.

As for the WASI version, I noticed you went with wasip1, wasip2, and wasip3 instead of e.g. 0.1. Any specific reason why? If WASI 1 is going to be 1.0 then normalizing the format now I would think would be a good thing.

Alex Crichton (Jul 23 2026 at 23:06):

Sounds reasonable to me on the sdk bits yeah, given the release versioning/cadence there's really only the major part and everything else is pretty minor and/or inconsequential.

For the WASI versions that might make sense to just drop for Python. Python I think will probably always be just one, right? For example Python only compiles with the wasm32-wasip1 target right now I believe (for the WASI platform that is). In the future it sounded like this, in a major python version, switch to something different like wasm32-wasip3. In essence it doesn't really matter too much to guest code.

In theory what guest code wants, as you say, is the 0.3.x or 0.2.x or whatever version. Currently wasi-libc doesn't expose that information, though, so it can't be pulled from headers

Brett Cannon (Jul 27 2026 at 20:06):

Alex Crichton said:

Python I think will probably always be just one, right?

That _I_ compile, yes. But someone's custom compile could target a different WASI version.

Alex Crichton said:

given the release versioning/cadence there's really only the major part and everything else is pretty minor and/or inconsequential.

As in only expose the major version?

Alex Crichton said:

In theory what guest code wants, as you say, is the 0.3.x or 0.2.x or whatever version. Currently wasi-libc doesn't expose that information, though, so it can't be pulled from headers

What's the expectation once 1.0 is reached? This all goes away and it's just version 1 forever? I'm not wedded to 01. versus p1, but I just want to be consistent for the eventual WASI 1 and how that will be exposed to users. If the best option is exposing the OS part of the target triple for compiling then I can do that. This may also influence the format of the platform tag for wheels when we get around to standardizing that, so I want to make sure to get this right once. :grinning_face_with_smiling_eyes:

Alex Crichton (Jul 27 2026 at 20:08):

On one hand we're talking about a hypothetical future state so all we can really do is put forth our best guess, but on the other hand, yes, I believe the current assumption is that once WASI reaches 1.0 it'll just stay there and not have a 2.0. The goal here being that it's a stable foundation by which other languages can build on (e.g. python/rust/etc)

Alex Crichton (Jul 27 2026 at 20:08):

Currently at least in Rust it's differentiated with cfg(target_env = "p2") where I'd like to keep versions out of the picture if possible

Brett Cannon (Jul 28 2026 at 19:46):

Alex Crichton said:

Currently at least in Rust it's differentiated with cfg(target_env = "p2") where I'd like to keep versions out of the picture if possible

If you're doing that for Rust I'm good with just following that in Python. Any plans to expose that string in wasi-libc to help with alignment? I can also just do what you do in your patch, but I will need to remember to ask what you do for WASI 1.

Alex Crichton (Jul 28 2026 at 20:26):

The wasi-libc equivalent is the __wasip{1,2,3}__ defines, there's no #define __wasi_version "p1" or similar yet

Alex Crichton (Jul 28 2026 at 20:26):

the set of wasi versions I'd expect is small enough though that needing manual adjustments here shouldn't be too hard

Last updated: Jul 29 2026 at 05:03 UTC