PEP 776: Emscripten Support

[oscarbenjamin]

@hoodmane

Where would be a good place to open an issue?

The relevant spot is here.

I’ve opened an issue: pip fails with `No module named 'encodings'` in pyodide venv · Issue #143 · pyodide/pyodide-build · GitHub

[freakboy3742 (Russell Keith-Magee)]

@hoodmane

Strictly speaking, CPython doesn’t control the packaging ecosystem. The code for pip, wheelhouse, manylinux, wheel, build, setuptools, etc all live in the PyPA organization not in the Python organization.

Granted; this is definitely an area where there the difference between “CPython” as a specific project “Python” as a language spec/community is significant. I probably should have said “an independent, Python-controlled standard”.

@hoodmane

We would like to upstream these into CPython runtime, and we are open to transferring control of the ABI to an organization that is bound tighter to the Python ecosystem than Pyodide.

Understood - my concern is that until such time as that upstreaming is complete and the control of the ABI is transferred to the Python ecosystem, there’s a risk of divergence; and that risk can be mitigated by not adopting pyodide directly as the standard, but instead using nomenclature (pyjs? pyweb?) that is identical to pyodide in practice (possibly even to the point that the terms are interchangeable in tooling), but gives space to diverge if the need arises.

I guess the other alternative would be to not standardise the pyodide meta-tag until such point as we are at a point where the relevant code has been upstreamed, and control of the ABI standard can be transferred.

@hoodmane

I’d be interested to hear more opinions on the “should this be two peps” question.

The Emscripten spec is a little longer than other platform PEPs (like PEP 730 and 738) because the binary ABI and other quirks of the platform require more explanation; but I’m not convinced that length is a good reason to split the PEP into two. If nothing else, the two underlying issues (platform details and wheel spec) aren’t completely orthogonal - they inform and influence each other, IMHO.

The one argument I could see for having 2 PEPs would be to split the pyodide wheel tag spec out from this “Emscripten platform” PEP. That would mirror PEP 600 being a standalone PEP for the meta tag that doesn’t address specific platform issues, other than what aspects of the platform are defined by the pyodide specification - and also means we could defer defining that tag until such time as responsibility for the definition is in a position to be transferred to Python.

[pf_moore (Paul Moore)]

Organisationally, it has to be two PEPs. The matters that affect core Python need to be decided by the SC, whereas the packaging issues need to be decided by me (or another packaging PEP delegate). The SC have made it clear in the past that they don’t want to decide packaging PEPs (you can ask them if they want to change their mind, but I think it’s unlikely) and I can’t make decisions on core PEPs.

[hoodmane (Hood Chatham)]

Okay I will go ahead and split it.

[freakboy3742 (Russell Keith-Magee)]

Closing the loop on this: PEP 783 (PR) separates the Emscripten packaging specification out from PEP 776.