Use emscripten-forge for WASM packages

[davidbrochart]

It would be nice to have these WASM wheels:

https://ds-wheels.s3.amazonaws.com/arro3_core-0.3.0-cp312-cp312-emscripten_3_1_58_wasm32.whl
https://ds-wheels.s3.amazonaws.com/arro3_compute-0.3.0-cp312-cp312-emscripten_3_1_58_wasm32.whl
https://ds-wheels.s3.amazonaws.com/arro3_io-0.3.0-cp312-cp312-emscripten_3_1_58_wasm32.whl
https://ds-wheels.s3.amazonaws.com/geoarrow_rust_core-0.3.0b1-cp38-abi3-emscripten_3_1_58_wasm32.whl

replaced with emscripten-forge packages, so that they can be installed and managed by a proper package manager.
What do you think?

[kylebarron]

The arro3 wheels will be provided by pyodide's registry with their next release: pyodide/pyodide#5020

I plan to add geoarrow-rust wheels to pyodide when I publish an 0.3.0 release.

I'm following this issue for what pyodide decides on for its wheel solution.

I don't really want to deal with another package manager yet, at least while these libraries have rapid iteration. PyPI + Conda + Pyodide is already a lot to manage

[agriyakhetarpal]

Hopefully, we'll move towards getting PyPI support for Pyodide/Emscripten wheels someday – it would require a PEP, though. Support in cibuildwheel via pypa/cibuildwheel#1456 was the first step, which has been accomplished.

[kylebarron]

That would be awesome, but seems like having to match Emscripten ABI compatibility makes that super hard to do

[agriyakhetarpal]

Yes. Ideally, if we do it, that would make our updates to match Emscripten's releases less frequent. We changed the default ABI tag recently from emscripten3_1_58 to pyodide_2024_0, so updating twice a year (or less) would be a reasonable option.