RFC Package unvendored stdlibs to sdist / wheel?

[ryanking13]

Proposed refactoring or deprecation

We are "unvendoring" some libraries to reduce the size of the Pyodide main module, and these libraries are being built as recipes like any other package. However, these libraries are handled somewhat differently than other packages; for example, they are defined as a separate cpython_module type, and they are installed in a different directory and process.

I recently noticed that the standard libraries being removed from Python 3.13 have been packaged separately and put on PyPI at this link, and I thought we might package the unvendored libraries similarly; consider them as normal python package and make a sdist (if they include c source codes) or wheel (if they are pure python).

If we package them as a normal Python package, it might be possible to reduce the specialized branches for those libraries, reducing the overall complexity of our build system.

Possible Drawbacks

1. We need to manage the source code for those libraries separately, for instance, in the pyodide/uncensored-libs repository, and we need to update them whenever we update the Python version. This can increase the maintenance burden.
2. We still need to know which packages come from standard libraries, and we have the fullStdLib option in loadPyodide.

So... this is just a thought, not a strong opinion, and I'm not even sure it's a good idea.

[hoodmane]

What about the unvendored binary extensions?

[ryanking13]

For binary extensions, we will still need to build them from sdist.

[hoodmane]

we will still need to build them from sdist

So you're proposing uploading sdists of CPython to pypi? Are they independent of the rest of the CPython source tree? This seems like an interesting idea, but I think there's no guarantee about builtin C modules successfully building in this way at this point or in the future. Though if it works for a while and then stops working we could just switch back.