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.
(downloading_deploying)=

# Downloading and deploying Pyodide

## Downloading Pyodide

### CDN

Pyodide packages, including the `pyodide.js` file, are available from the JsDelivr CDN,

| channel             | indexURL                                         | Comments                                                                                 | REPL                                               |
| ------------------- | ------------------------------------------------ | ---------------------------------------------------------------------------------------- | -------------------------------------------------- |
| Latest release      | `https://cdn.jsdelivr.net/pyodide/v0.19.0/full/` | Recommended, cached by the browser                                                       | [link](https://pyodide.org/en/stable/console.html) |
| Dev (`main` branch) | `https://cdn.jsdelivr.net/pyodide/dev/full/`     | Re-deployed for each commit on main, no browser caching, should only be used for testing | [link](https://pyodide.org/en/latest/console.html) |

To access a particular file, append the file name to `indexURL`. For instance,
`"${indexURL}pyodide.js"` in the case of `pyodide.js`.

```{warning}
The previous CDN `pyodide-cdn2.iodide.io` is deprecated and should not be used.
```

### GitHub releases

You can also download Pyodide packages from [GitHub
releases](https://github.com/pyodide/pyodide/releases)
(`pyodide-build-*.tar.bz2` file) serve them yourself, as explained in the
following section.

(serving_pyodide_packages)=

## Serving Pyodide packages

If you built your Pyodide distribution or downloaded the release tarball
you need to serve Pyodide files with appropriate headers.

### Serving locally

With Python 3.7.5+ you can serve Pyodide files locally by starting

```
python -m http.server
```

from the Pyodide distribution folder.

Point your WebAssembly aware browser to
[http://localhost:8000/console.html](http://localhost:8000/console.html) and open
your browser console to see the output from Python via Pyodide!

### Remote deployments

Any solution that is able to host static files and correctly sets WASM
MIME type, and CORS headers would work. For instance, you can use GitHub Pages
or similar services.

For additional suggestions for optimizing size and load times, see the [Emscripten
documentation about deployments](https://emscripten.org/docs/compiling/Deploying-Pages.html).

(downloading_deploying)=

# Downloading and deploying Pyodide

## Downloading Pyodide

### CDN

Pyodide packages, including the `pyodide.js` file, are available from the JsDelivr CDN,

| channel             | indexURL                                         | Comments                                                                                 | REPL                                               |
| ------------------- | ------------------------------------------------ | ---------------------------------------------------------------------------------------- | -------------------------------------------------- |
| Latest release      | `https://cdn.jsdelivr.net/pyodide/v0.19.0/full/` | Recommended, cached by the browser                                                       | [link](https://pyodide.org/en/stable/console.html) |
| Dev (`main` branch) | `https://cdn.jsdelivr.net/pyodide/dev/full/`     | Re-deployed for each commit on main, no browser caching, should only be used for testing | [link](https://pyodide.org/en/latest/console.html) |

To access a particular file, append the file name to `indexURL`. For instance,
`"${indexURL}pyodide.js"` in the case of `pyodide.js`.

```{warning}
The previous CDN `pyodide-cdn2.iodide.io` is deprecated and should not be used.
```

### GitHub releases

You can also download Pyodide packages from [GitHub
releases](https://github.com/pyodide/pyodide/releases)
(`pyodide-build-*.tar.bz2` file) serve them yourself, as explained in the
following section.

(serving_pyodide_packages)=

## Serving Pyodide packages

If you built your Pyodide distribution or downloaded the release tarball
you need to serve Pyodide files with appropriate headers.

### Serving locally

With Python 3.7.5+ you can serve Pyodide files locally by starting

```
python -m http.server
```

from the Pyodide distribution folder.

Point your WebAssembly aware browser to
[http://localhost:8000/console.html](http://localhost:8000/console.html) and open
your browser console to see the output from Python via Pyodide!

### Remote deployments

Any solution that is able to host static files and correctly sets WASM
MIME type, and CORS headers would work. For instance, you can use GitHub Pages
or similar services.

For additional suggestions for optimizing size and load times, see the [Emscripten
documentation about deployments](https://emscripten.org/docs/compiling/Deploying-Pages.html).
