Disabled package tracker for 0.28 release

@hoodmane

Following packages are currently disabled in the main branch, which is a (soft) blocker for Pyodide 0.28 release. It is not mandatory to enable all the packages for the release (we can mention it in the release note and fix it later or ask others' help), but it would be nice to enable packages that are easy to fix.

This issue is to track the status of the disabled packages:

Requires maintainers to provide a wheel with new xbuildenv

arro3-io (Request to update Pyodide build toolchain version kylebarron/arro3#343), done via feat: PEP 783 Emscripten wheels! kylebarron/arro3#502
arro3-compute
arro3-core
polars
- has emscripten 4.0.9 build, but it should be recompiled with wasm-exception enabled.
- now done; see Re-added support for Polars #519
css-inline (Request to update Pyodide build toolchain version Stranger6667/css-inline#447), chore: Update recipe for css-inline #112
pyarrow (Reenable pyarrow #438)
osqp
- it use CIBW, so probably CIBW should make a release including Add pyodide 0.28 pypa/cibuildwheel#2431?
duckdb (Request to update Pyodide build toolchain version duckdb/duckdb-pyodide#7)

Lacks Python 3.13 support

gensim: No 3.13 compatible release
zarr - added back via Re-enable Zarr 3 support #584. The latest release that supports 3.13 requires threading module – will be hopefully resolved with Add Pyodide support and CI jobs for Zarr zarr-developers/zarr-python#1903 landing upstream, after which we can remove it from this repo.
pygame-ce: the latest release that supports 3.13 changed the build backend to meson, but it does not support emscripten platform

Has build issue

casadi: Re-enable CasADi #89
clarabel
- cvxpy-base (depends on clarabel)
pyproj: signature mismatch (Fix pyproj #436)
- geopandas (depends on pyproj)
- Cartopy (depends on pyproj)
RobotRaconteur: No idea (fixed by maintainer: Fix RobotRaconteur with Emscripten 4.0.9 pyodide#5677)

My idea is to

enable all possible packages in [1] by asking maintainers to update the packages (we can probably give some deadline)
Enable casadi, pyproj, which I think is easy to fix.
2.a) Personally, I would like to fix pygame as well, but it doesn't seem easy
Leave other packages disabled, make a release, and fix them later.

@hoodmane @agriyakhetarpal WDYT?

@hoodmane

Your idea sounds good to me!

In the interest of time, I'll go ahead with CasADi, which we do have a stopgap solution for. We can take a look at the SUNDIALS_EXPORT issue later; I'll open an issue to keep track of it.
2 Re: Zarr; the use of threading is also a reason why Add Pyodide support and CI jobs for Zarr zarr-developers/zarr-python#1903 was blocked back then, but on another look, I see that we should be able to set
```
zarr.config.set({
    "threading.max_workers": 1,  # or None?
    "async.concurrency": 1,
})
```

in order to restrict all IO operations that rely on multiple threads. Maybe that snippet can be added at init time and things would work? I'll also revisit my PR.
3. If gensim has no release supporting Python 3.13, we should leave it out, and if someone raises a request to add it back, we can do so with 0.28.x releases or when Python 3.13 support lands, whichever comes first – like you mentioned in point 3. It is already being discussed in piskvorky/gensim#3611, and I've spotted @hoodmane in piskvorky/gensim#3601 :D
4. For packages that require a new build with nightly xbuildenvs, I assume we've frozen our Emscripten updates with the 4.0.9 release, and we can ask them to use the one from 20th May, i.e., https://github.com/pyodide/pyodide-build-environment-nightly/releases/tag/20250520? If we have any more updates, another xbuildenv will come out with them tomorrow.
5. I think pygame-ce should be included if possible, as it took a reasonable time to support in the first place. However, I understand the necessities of the release timeline as well. Also, you did manage to fix pyxel in #98, so only one game engine is left. :)
6. Clarabel has had a new 0.11 release, maybe things are fixed now? https://github.com/oxfordcontrol/Clarabel.rs/releases/tag/v0.11.0

Also, should we tag the respective package maintainers here itself?

in order to restrict all IO operations that rely on multiple threads. Maybe that snippet can be added at init time and things would work?

Yeah, it would be worth checking if it works.

we can ask them to use the one from 20th May, i.e., https://github.com/pyodide/pyodide-build-environment-nightly/releases/tag/20250520? If we have any more updates, another xbuildenv will come out with them tomorrow.

It should be https://github.com/pyodide/pyodide-build-environment-nightly/releases/tag/20250523-emscripten_4.0.9. 20250520 contains Emscripten 4.0.8 (The GitHub releases UI sorts the releases strangely).

Clarabel has had a new 0.11 release, maybe things are fixed now?

Thanks for the info. Let's try.

@pmp-p

I think pygame-ce should be included if possible, as it took a reasonable time to support in the first place. However, I understand the necessities of the release timeline as well. Also, you did manage to fix pyxel in Use emscripten 4.0.9 and enable pyxel #98, so ozly one game engine is left. :)

I tried it once, but it wasn't straightforward. Maybe we need some help from pygame maintainers.

Hi, @pmp-p, does pygbag support Python 3.13? I wonder if you managed to make pygame>=2.5.1 work in pygame-web.

Also, should we tag the respective package maintainers here itself?

Yeah, let me open an issue for each repository and mention them in this issue as well for visibility.

Ah yes, thanks for the link to the newer nightly!

I tried to build Clarabel 0.11, but it keeps failing with error: the option Z is only accepted on the nightly compiler despite the fact that I've set the nightly toolchains as default and I've the Rust sysroot based on our ABI docs. I'll try to debug that at a later point. In the meantime, I'll take a look at Zarr 3.

It seems Marimo is blocked from updating by in particular pyarrow, polars, and duckdb.

marimo-team/marimo#5995 (comment)

And I'm in turn blocked by them not updating so I can use ngspice.

It seems duckdb progress is well underway, and polars sounds simple but doesn't have an issue linked?

But pyarrow seems a bit more problematic as there hasn't been any movement in the issue and there is still an open issue for 0.27 that seems to have resulted in pyodide hosting their own build?

What's the latest news on this?

It seems polars is close to working? feat: Build and test against Pyodide 0.29 (new pyodide_2025_0 ABI) pola-rs/polars#24058
pyarrow-pyodide is kinda unmaintained so maybe we need to just ship that in pyodide recipes?
duckdb seems to be done but not hosted anywhere? Request to update Pyodide build toolchain version duckdb/duckdb-pyodide#7

[edit] oh, I guess pyarrow progress is now being made here? apache/arrow#47330

@pepijndevos

@pepijndevos I requested duckdb developers to upload the wheel. For pyarrow and polars, I am not actively following the status but @agriyakhetarpal might know.

What needs to be done to unblock geopandas? I know this depends on pyproj, has anyone reported an issue there already or is there something that needs to be done on pyodide side?

@krassowski

@krassowski

Yep pyproj is blocking geopandas and #356 is trying to fix the pyproj. If you are interested, please take a look.

Since it seems like it will take a while before Marimo can update to 0.28, is there a way to build the libngspice recipe as a standalone thing (wheel? so?) for 0.27 that I can load in marimo?

Is that a matter of running these instructions on an older pyodide-build? #373 (comment)

@pepijndevos

@pepijndevos

Yes, you can build ngspice targetting Pyodide 0.27, host is somewhere and load it from marimo.

Is that a matter of running these instructions on an older pyodide-build? #373 (comment)

You don't need to install old pyodide-build. pyodide-build support multiple Pyodide versions.

Since Pyodide 0.27 uses Python 3.12, you need to setup local Python version to 0.27, and run

pyodide xbuildenv install 0.27.3

and run the rest of the commands in the comment. It will build the ngspice wheel targetting Pyodide 0.27

That almost worked, but libngspice is a shared library so only produces a zip file instead of a wheel, and micropip only installs wheels afaik.

Should I

change libngspice to a package type? -- fails because there is no setup.py
build the inspice wheel so it'll include libngspice? -- doesn't seem to include or load the zip
load the zip file some other way? -- I can only find this approach but Marimo hardcodes the indexURL

btw I had to run pyodide build-recipes-no-deps libngspice otherwise there would be some horrendous failure on the test package: emcc: error: Modules/_testcapi/pyatomic.c: No such file or directory ("Modules/_testcapi/pyatomic.c" was expected to be an input file, based on the commandline arguments provided) which I suspect may be because the recipe repository was never meant to be built for 0.27?

That almost worked, but libngspice is a shared library so only produces a zip file instead of a wheel, and micropip only installs wheels afaik.

Oh yeah, that's a bit of a tricky part... what Pyodide does for the shared libraries in the lock file is simply unpacking it to the /usr/lib directory. So you do the similar thing: fetching the file and unpacking it to the directory (doc)

build the inspice wheel so it'll include libngspice? -- doesn't seem to include or load the zip

If possible, this is the recommended way. Pyodide supports loading the shared library inside the wheel's .libs directory (following the convention of the auditwheel. But you should check if the inspice wheel itself supports that (if it is hardcoding the path to load the shared library, it may not work).

("Modules/_testcapi/pyatomic.c" was expected to be an input file, based on the commandline arguments provided) which I suspect may be because the recipe repository was never meant to be built for 0.27?

Yeah, it is because that package expects Python 3.13's test package. You can ignore that.

Okay getting closer...

I did:

conda create -n "pyodide027" python=3.12.7 pyodide-build
conda activate pyodide027
pyodide xbuildenv install 0.27.7

git clone https://github.com/emscripten-core/emsdk
cd emsdk
./emsdk install $(pyodide config get emscripten_version)
./emsdk activate $(pyodide config get emscripten_version)
source emsdk_env.sh
cd ..

pyodide build-recipes-no-deps libngspice

Marimo:

import pyodide
pyodide.__version__
'0.27.7'
import sys
sys.version
'3.12.7 (main, Jun  4 2025, 22:38:17) [Clang 19.0.0git (https:/github.com/llvm/llvm-project 0a8cd1ed1f4f35905df318015b'

Conda:

$ pyodide xbuildenv versions
* 0.27.7
$ python --version
Python 3.12.7
$ pyodide config get emscripten_version
3.1.58

Marimo installation:

from pyodide.http import pyfetch
response = await pyfetch("http://localhost:8080/wheels/libngspice-44.2.zip")
await response.unpack_archive(format="zip", extract_dir="/usr/lib")

Trying to use libngspice:

OSError

    cannot load library '/usr/lib/libngspice.so': Could not load dynamic lib: /usr/lib/libngspice.so LinkError: imported function 'env.time' signature mismatch. Additionally, ctypes.util.find_library() did not manage to locate a library called '/usr/lib/libngspice.so'
    See the console area for a traceback.

So it seems there is some version mismatch, but afaict the environments all match.

Ah we've been there: pyodide/pyodide#5601 (comment) so this is a problem specific to the ngspice recipe and libtool

Looking at the linked comment, I think it was related to WASM_BIGINT flag.

@kylebarron

We have been able to clear the queue on almost all packages here now, and I have noted the following as the status for the remaining ones:

arro3-io (Request to update Pyodide build toolchain version kylebarron/arro3#343)

arro3-compute

arro3-core

Following PEP 783, it would be great if arro3-namespace packages could start publishing for the 2025 ABI, and (soon) the 2026 ABI, to PyPI. cibuildwheel v4 has an rc2 available with Pyodide 0.29.4 available for the 2025 ABI and Pyodide 314.0.0a2 available under the pyodide-prerelease option, and a final release is coming out. The Pyodide 314.0 stable release is also coming out soon (pyodide/pyodide#6233), and it can land either into cibuildwheel v4, or a v4.1 later. pyodide-build as a standalone package will still be usable for building wheels, though. Tagging @kylebarron as the recipe maintainer for visibility.

gensim: No 3.13 compatible release

This one is not applicable anymore, because we use Python 3.14 now, and while gensim now supports Python 3.13, it does not yet support Python 3.14. Linking these three items: piskvorky/gensim#3627, piskvorky/gensim#3628, piskvorky/gensim#3633. We have no recipe maintainer listed, so tagging @Amodio from the original PR at pyodide/pyodide#3326 for visibility (sorry – I know that PR is very old, but just in case you're interested!).

osqp

it use CIBW, so probably CIBW should make a release including Add pyodide 0.28 pypa/cibuildwheel#2431?

Along similar lines, it would be great if osqp could support PEP 783 to publish Pyodide wheels to PyPI. Tagging @vineetbansal as the recipe maintainer for visibility.

For reference, the necessary documentation is at https://pyodide-build.readthedocs.io. Please reach out in case there are issues with building!

I saw https://blog.pyodide.org/posts/314-release/ and got excited! kylebarron/arro3#502 sets up the pyo3-based CI to build and publish arro3-core and arro3-compute wheels for emscripten to PyPI. (arro3-io is left for later since it currently pulls in a mix of async code). I'll try to publish a new version tomorrow

Navigation Menu

Repository navigation

Disabled package tracker for 0.28 release #99

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Disabled package tracker for 0.28 release #99

Description

Activity

agriyakhetarpal commented on May 26, 2025

ryanking13 commented on May 26, 2025

ryanking13 commented on May 26, 2025

ryanking13 commented on May 26, 2025

agriyakhetarpal commented on May 26, 2025

pepijndevos commented on Aug 11, 2025

pepijndevos commented on Oct 13, 2025

ryanking13 commented on Oct 16, 2025

krassowski commented on Oct 23, 2025

ryanking13 commented on Oct 26, 2025

pepijndevos commented on Nov 11, 2025

ryanking13 commented on Nov 12, 2025

pepijndevos commented on Nov 12, 2025

ryanking13 commented on Nov 13, 2025

pepijndevos commented on Nov 14, 2025

pepijndevos commented on Nov 15, 2025

ryanking13 commented on Nov 17, 2025

agriyakhetarpal commented on Jun 7, 2026

kylebarron commented on Jun 10, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions