Our package build process currently has a significant flaw: we first run `setup.py`, recording all compilation commands, then we rewrite these compilation commands to invoke `emcc` and replay them, and then we pray that the cross compiled executables ended up in the right place to go into the wheel. This is not a good strategy because the build script is allowed to implement arbitrary logic, and if it moves, renames, etc any of the output files then we lose track of them. This has repeatedly caused difficulty for us.

However, we also make no particularly significant use of the two pass approach. We can just do the simpler thing: capture the compiler commands as they occur, modify them as needed, and then run the fixed command.

I also added a patch to fix the numpy feature detection for wasm so that we don't have to include `_npyconfig.h` and `config.h`, numpy can generate them in the way it would for a native build. I opened a numpy PR that would fix the detection for us upstream:
https://github.com/numpy/numpy/pull/21154

This clears the way for us to switch to using pypa/build (as @henryiii has suggested) by removing our dependence on specific setuptools behavior.

This is on top of #2238.
No replay. Our package build process currently has a significant flaw: we first run `setup.py`, recording all compilation commands, then we rewrite these compilation commands to invoke `emcc` and replay them, and then we pray that the cross compiled executables ended up in the right place to go into the wheel. This is not a good strategy because the build script is allowed to implement arbitrary logic, and if it moves, renames, etc any of the output files then we lose track of them. This has repeatedly caused difficulty for us.

However, we also make no particularly significant use of the two pass approach. We can just do the simpler thing: capture the compiler commands as they occur, modify them as needed, and then run the fixed command.

I also added a patch to fix the numpy feature detection for wasm so that we don't have to include `_npyconfig.h` and `config.h`, numpy can generate them in the way it would for a native build. I opened a numpy PR that would fix the detection for us upstream:
https://github.com/numpy/numpy/pull/21154

This clears the way for us to switch to using pypa/build (as @henryiii has suggested) by removing our dependence on specific setuptools behavior.

This is on top of #2238.
# Pyodide Python package

A Python package providing core interpreter functionality for Pyodide.

This package is an integral part of the Pyodide runtime which cannot start
without it. Install in a native Python for type checking or testing purposes.
Some of the functionality is missing when imported in a native Python, but for
the APIs we either provide reimplementations or nonfunctional type stubs.

## License

Pyodide uses the [Mozilla Public License Version
2.0](https://choosealicense.com/licenses/mpl-2.0/).

## Design information for Pyodide contributors

This directory consists of two Python packages py/\_pyodide and py/pyodide. The
difference between these packages is when they are imported. They are both
imported by core/pyodide as a part of setting up the Pyodide/javascript foreign
function interface.

py/\_pyodide is imported as the first step after initializing
the CPython interpreter. py/\_pyodide cannot have any import time dependencies
other than the CPython stdlib.

py/pyodide is imported as the final step of core/pyodide. It has an import time
dependency on `_pyodide_core` which is a Python C extension assembled by
core/pyodide to serve the needs of py/pyodide.

# Pyodide Python package

A Python package providing core interpreter functionality for Pyodide.

This package is an integral part of the Pyodide runtime which cannot start
without it. Install in a native Python for type checking or testing purposes.
Some of the functionality is missing when imported in a native Python, but for
the APIs we either provide reimplementations or nonfunctional type stubs.

## License

Pyodide uses the [Mozilla Public License Version
2.0](https://choosealicense.com/licenses/mpl-2.0/).

## Design information for Pyodide contributors

This directory consists of two Python packages py/\_pyodide and py/pyodide. The
difference between these packages is when they are imported. They are both
imported by core/pyodide as a part of setting up the Pyodide/javascript foreign
function interface.

py/\_pyodide is imported as the first step after initializing
the CPython interpreter. py/\_pyodide cannot have any import time dependencies
other than the CPython stdlib.

py/pyodide is imported as the final step of core/pyodide. It has an import time
dependency on `_pyodide_core` which is a Python C extension assembled by
core/pyodide to serve the needs of py/pyodide.
