Thanks for the response @dstufft!
emscripten is a compiler that can turn C/C++ code into wasm that specifically is targeting the browser … they’ve had to make a lot of decisions on how to expose certain things like filesystems, etc that means they’re also kind of like an OS in the traditional sense
Yes, Emscripten is a compiler, operating system, and collection of system libraries for running C/C++ code in JavaScript runtimes. But it’s not just one ABI/operating system it is a bunch of them depending on a bunch of linker “settings” flags. They also provide no guarantees of ABI compatibility between Emscripten patch releases so in principle Emscripten 5.0.1 is a completely unrelated platform from Emscripten 5.0.2.
So emscripten is comparable in some ways to the linux tag. But unlike the manylinux situation, the different ABIs are not forwards compatible, so a program compiled to target an old one will not work with a new one or even with the same version but with different ABI-sensitive flags. Thus, there is no possibility of manyemscripten.
pyodideis a Python interpreter that is intended to target the wasm virtual machine on top of the runtime provided by emscripten.
pyodide consists of the following components:
- CPython with a few patches (on the order of 45 lines of diff)
- A JS/Python ffi like ctypes for JS runtimes (upstreaming this is the subject of pep 818)
- A choice of Emscripten version + ABI-sensitive flags + static libraries to link
- A toolchain for cross compiling and testing packages for this platform
So in some sense it is a Python interpreter but it is not a distinct intepreter from CPython.
The tag is
pyodide_{PYTHON_MAJOR_MINOR}_{PATCH}_wasm32, but none of our other platform tags include the Python major version in them, or really anything about the Python version at all.
Until last week I had pyodide_{YEAR}_{PATCH}_wasm32 as the platform tag. I’m thinking we should switch back to using the year since it is a bit confusing to use the Python version. The platform is component 3 above. Since Emscripten is not a well-defined platform, someone has to choose a specific Emscripten. Whether we call it pyodide or pyemscripten I don’t care. We have the following two constraints:
-
We want to benefit from improvements in functionality, code size, and performance that come with newer Emscripten versions and newer ABIs.
-
We want to avoid a combinatorial explosion of wheels.
So the idea is that we pick one platform per Python version. So it’s possible to build Python 3.13 or indeed a completely unrelated C program with the pyodide_2026_0 platform (or whatever we decide to call it). We’ve just decided by convention to use it with Python 3.14.
This makes abi3 wheels no better than dedicated wheels because the cp37-abi3-pyodide_2026_0 wheel works with Python interpreters >= 3.7 built for the pyodide_2026_0 platform but we’re only ever planning to build Python 3.14 for the pyodide_2026_0 platform. But there is nothing stopping anyone from building other Python interpreters for that platform.
cryptography-44.0.2-po029-2025_0-wasm32_emscripten.whl
Well:
- Pyodide is CPython so we should use cp for the interpreter tag. There are minor differences but our goal is to make them go away in the next few years. In particular,
sys.implementation.namein Pyodide iscpython. 2025_0-wasm32_emscriptenseems a bit too vague. How do we know where to go for the platform definition? It’s not defined by Emscripten. I like eitherpyodideorpyemscriptenin the platform better. I suppose we could say that our platform is2025_0-wasm32_emscriptenbut it seems to me that some other ecosystem could define a conflicting notion of what that means.
say I decide to build a retro Python 2.7 for Emscripten, what would it mean for my Python to be runnable on pyodide_2025_0_wasm32?
It’s documented here: Pyodide Platform ABI
My understanding is the capabilities of the platform is tied to what emscripten supports, not what Pyodide supports, so it feels like the platform tag here should be focused on Emscripten (it’s not clear to me if it needs to be versioned like Manylinux or macOS is or whether it can be unversioned like windows is).
This is right. We can’t call it manyemscripten since it won’t even work with all binaries compiled and linked with Emscripten 5.0.1, only those that also pass specific additional flags. I think pyemscripten works well with this. But we can’t just use the Emscripten version since as I said 5.0.1 is too vague. Either the year or the Python version could go here but I think the year is better since the Python version is conceptually confusing.
Most of the docs on the Pyodide ABI tag feels like it should just be part of the Pyodide interpreter tag and interpreter ABI
Did you look here? None of that is related to Python at all.
tl;dr
1. I’ll go ahead and change it to pyemscripten.
2. I was using the year until a couple of weeks ago when @thomas suggested switching to the Python version. But from what you said it seems that using the Python version is more confusing than helpful so I’m thinking we should go back to the year.
3. Explained above.
I’d like the platform tag limited to just be about emscripten itself
In the ideal case Emscripten would solve this for us by providing periodic named ABIs that everyone could standardize on. Or at least tell us when they break ABI. I know several other ecosystems like the Godot game engine that are having exactly the same problem as us. (Also, Rust is quite troublesome since they are only willing to support one stable Emscripten platform. Luckily, I am the maintainer of the Rust Emscripten target so I can keep us in sync.)
Since Emscripten has not shown interest thus far in solving this problem for the ecosystem, we have to do it ourselves one way or another. The plan of one platform per Python minor version allows us to gradually bring in improvements while also still being a stable enough platform that people can target.
It feels to me that modulo bikeshedding the platform name we are basically forced into this solution because of Emscripten’s posture.
I will add more detail about this situation to the pep.