Thanks for the clarifications. I’ll focus solelly on the packaging side of the PEP, which as far as I can see is essentially the Packaging section. I suggest that you frame this similarly to the manylinux and musllinux PEPs, as they are the closest equivalent we’ve had previously.
The “Packaging goals” seem reasonable, although I’m not sure describing the pyodide tooling is necessary here - that should go in the pyodide documentation, and simply be referenced in the PEP if and when relevant.
The discussion of the wheel format needs clarifying. “Emscripten wheels will use either the format emscripten_<version>_wasm32 or pyodide_<abi>_wasm32” - I assume you mean that these are platform tags, in which case you should say so, and probably clarify what ABI tag wheels should use (the ABI tags we have are very CPython-based, so may well not be applicable for emscripten). You also need to explain how to determine the supported tags for a given interpreter. You might also want to review the implementation of the manylinux and musllinux tags in packaging (here and here) to get a feel for how tags are implemented in practice.
You should probably also consider dependency specifiers (and in particular markers). If a library, written in pure Python, wants to use 3rd party code to replace a stdlib module that’s not supported in emscripten, they will almost certainly need to frame that dependency as “only needed on emscripten”. There’s a sys_platform tag, and other tags that explose values from the platform module, so this shouldn’t be an issue, but there’s no markers that expose sys._emscripten_info, so if that might be relevant in choosing dependencies, you’d need to consider adding extra markers.
You need to consider the backward compatibility implications on the packaging ecosystem. I think it’s fine - tools will simply ignore wheels with an unknown package tag - but it’s something that should be covered explicitly. New markers might be an issue, though, as older tools will fail if they encounter markers they don’t know about.
You may also want to consider adding a new classifier (which would need to be requested) to declare support (or not) for emscripten, which could be used by pure Python libraries.
There’s also the “How to teach this” section. I’m never clear on how much depth this section ought to go into - when reviewing PEPs I tend to rely on my own questions. With this PEP, I’d be asking:
- How do I adapt an existing build process to build emscripten wheels? Or at least, try to do so - I may be OK with building emscripten wheels if it’s straightforward, but not want to get deeply into the emscripten ecosystem.
- How do I run my tests against emscripten? Particularly for a pure Python project, where I’d by default assume my code works “everywhere”.
- Assuming I don’t want to get sucked into fully supporting emscripten, what do I do if my tests fail?
- And for that matter, what do I do if my tests succeed? (This is where “Add a classifier saying the code works on emscripten” comes in).
The “How to teach this” section isn’t the right place to answer these questions, but it should discuss how we’ll ensure that people with such questions can find answers.