WHL: build WebAssembly (Pyodide) wheels - #20171

AI prompts:

Can you test locally, on nstarman/astropy, and then opening a PR to astropy to address #18898. Don't actually open the PRs without asking me first. Let me review the changes and the PR text.

Does OpenAstronomy/github-actions-workflows#404 make me opening a PR to OpenAstronomy unnecessary ?

Ok. Open a draft PR to astropy using OpenAstronomy/github-actions-workflows#404 and commenting that the Astropy PR requires that to land first.
Reference that this closes the #18898 issue.

Description

This pull request is to address building WebAssembly wheels, so that astropy can be
pip installed under Pyodide/PyScript rather than relying on the copy vendored in the
Pyodide distribution. PEP 776 and PEP 783 are accepted, and cibuildwheel builds
pyemscripten_*_wasm32 wheels out of the box — no enable flag needed — so this is just
one more entry in targets.

Fixes #18898

Blocked on OpenAstronomy/github-actions-workflows#404

The pinned reusable workflow sets CIBW_PLATFORM nowhere, and cibuildwheel infers the
platform from the runner OS — linux, not pyodide — so the job would select no builds
and fail. The workarounds don't work here: setting it through the env: input applies it
to every target and would break the native wheels, and a second call to the reusable
workflow doesn't help either because our upload job globs dist-* across the whole run,
so both calls would try to publish the same files.

OpenAstronomy/github-actions-workflows#404 adds per-target CIBW_PLATFORM (it absorbed
OpenAstronomy/github-actions-workflows#345). Once it lands, the pin on line 29 of
publish.yml needs bumping to a release containing it — until then this PR is a draft.

That PR also moves cibuildwheel 4.0.0 → 4.1.1, which enables cp314-pyodide_wasm32
alongside cp313, so the glob above produces two wheels. They carry different Emscripten
ABI years (pyemscripten_2025_0 and pyemscripten_2026_0) and do not collide.

Testing

Locally, with cibuildwheel 4.1.1 on macOS:

• cp313-pyodide_wasm32 (Pyodide 0.29.4 / Emscripten 4.0.9) and cp314-pyodide_wasm32
  (Pyodide 314.0.2 / Emscripten 5.0.3) both build in ~2 min. EXTENSION_HELPERS_PY_LIMITED_API=cp311
  applies to the wasm builds too, so each is a single abi3 wheel.
• Runtime dependencies resolve from the Pyodide CDN (numpy, pyerfa, pyyaml);
  astropy-iers-data and packaging come from PyPI as pure-Python wheels.
• Smoke test under node on both: SkyCoord(10*u.deg, 20*u.deg).galactic →
  (119.26936774, -42.79039286), Time("2026-01-01").jd → 2461041.5, and
  astropy.stats._fast_sigma_clip imports, so the compiled extensions and pyerfa are
  live.
• Out of curiosity, pytest --pyargs astropy.units under Pyodide: 3671 passed, 58 skipped,
  3 xfailed.

End-to-end on a fork against the head of OpenAstronomy/github-actions-workflows#404, with a
targets list of one native target plus the pyodide glob —
https://github.com/nstarman/astropy/actions/runs/30555396042:

• pyodide job: CIBW_PLATFORM: pyodide, skip_config: *-musllinux_x86_64 *-pyodide_wasm32,
  two wheels produced, no tests run.
• cp313-manylinux_x86_64: CIBW_PLATFORM empty, i.e. behaviour unchanged. Full test suite
  green — 26957 passed, 3753 skipped, 84 deselected, 254 xfailed.

On not testing the wasm wheels

test-skip covers pyodide for now. The reusable workflow sets a single CIBW_TEST_COMMAND
for every target and cibuildwheel's environment variables win over per-platform
pyproject.toml overrides, so pyodide can't be given a lighter test command while the other
targets keep the full suite. astropy.units passing suggests wiring up a real test run is
feasible later, but chunks of the suite need threads, sockets and subprocesses that
WebAssembly doesn't have.