uv sync fails on CI: greenlet==3.5.2 has no Linux wheels

[AlexandreAndr]

I have this job that is failing job.

with this error

Using CPython 3.10.20 interpreter at: /opt/hostedtoolcache/Python/3.10.20/x64/bin/python3
Creating virtual environment at: .venv
Resolved 258 packages in 3.27s
error: Distribution `greenlet==3.5.2 @ registry+[https://pypi.org/simple`](https://pypi.org/simple%60) can't be installed because it doesn't have a source distribution or wheel for the current platform

hint: You're on Linux (`manylinux_2_39_x86_64`), but `greenlet` (v3.5.2) only has wheels for the following platforms: `macosx_11_0_universal2`, `win_amd64`
Error: Process completed with exit code 2.

greenlet 3.5.2 was released with wheels only for macOS and Windows. Our CI runs uv sync --all-extras without --frozen, which allows uv to re-resolve and pick up the new version, causing the install to fail on Linux.

Root cause: greenlet is a transitive dependency (jupyter-cache → sqlalchemy → greenlet) and was not pinned to the committed lock file version.

Fix (2 options):

• Add the uv.lock and --frozen to uv sync in both CI workflows so the committed uv.lock (which has greenlet==3.5.1 with Linux wheels) is used as-is.
• Add on the dependencies greenlet==3.5.1

[AlexandreAndr]

Option 2 fix is here #311
I think option 1 would be better but if we want to handle it later we can start with option 2 as a hotfix

[vinamarora8]

I reran the action here and it seems to have gone through. I think this was just a transient issue related to greenlet==3.5.2 having been released ~11 hours ago, which is roughly the time your failing job was run.

[AlexandreAndr]

Okay great news, thanks for checking! Do we want to keep a discussion on the uv lock? I'll close the PR with option 2

[vinamarora8]

Yes, we can keep it open for that. I am sympathetic to the idea using uv.lock for CI. Though we have not been keeping it up to date at all.