wasm32-emscripten CI additions
Future additions for the emscripten CI job:
Well there's a couple more things I'm interested in:
- I'd like to run the tests that mix Rust and C/C++. This is quite common in real packages.
- I'm working on a way to have Pyodide virtual environments https://github.com/pyodide/pyodide/pull/2976 this will lead to rather more graceful testing.
Originally posted by @hoodmane in https://github.com/PyO3/pyo3/issues/2412#issuecomment-1221315962
- [ ] Test async support after #3540
@hoodmane given there's been some time I wonder if you can share some thoughts on how relevant you think these ideas still are, and maybe lay out what resources I should look at to make the changes you had in mind? (Or if there's other things you'd recommend the PyO3 CI start to cover?)
I noticed that in Python 3.12 there is a tool to build wasm in tree. I wonder if we want to use this. Tools/wasm/wasm_build.py
Also we potentially want to test pyodide, maybe as a replacement for building in-tree cpython? (Or in addition to.)
given there's been some time I wonder if you can share some thoughts on how relevant you think these ideas still are
Well they are still relevant but the good news is that in practice it seems to work fine. My highest priority for Rust is to fix wasm-eh:
https://github.com/rust-lang/rust/issues/112195
https://github.com/emscripten-core/emscripten/issues/19612
Rust packages are the only things that can't build with wasm exception handling, but it seems to require fixing the try rustc intrinsic, so it won't work with current versions of rust.
Testing against Pyodide is pretty reasonable. The build settings that wasm_build.py produce are closely modeled on Pyodide's build settings so it should be similar. But IIRC the pyo3 tests want to statically link libpython into the test binaries so it would require some extra work to use Pyodide there.
Updated the OP to add a note for async tests after #3540 merges