Thanks for your perspective. I understand your concern about the effort required to build a collection of extensions, but I want to clarify that emscripten-forge is not aiming to replicate Pyodide. Pyodide is indeed a comprehensive platform with its own API, packaging system, and tooling. Our goal with emscripten-forge is to provide a minimal, modular, and distribution-agnostic foundation for WebAssembly-based Python distributions.
The key point is that the wheel format should not be tied to Pyodide’s full ecosystem. Instead, it should represent a shared ABI that any distribution (Pyodide, emscripten-forge, or others) can build upon. This would allow Pyodide to continue innovating with its rich API and tooling, while also enabling other distributions to coexist and interoperate.
For example, emscripten-forge uses a different JavaScript-Python bridge (pyjs) and supports a broader range of languages and tools. We don’t want to fragment the ecosystem, but we also don’t want the wheel format to implicitly require adoption of Pyodide’s entire stack.
A neutral format like emscripten_${YEAR}_${PATCH}_wasm32 would ensure that packages built for one distribution can work in others, as long as they adhere to the same ABI.