Sync plugins/uv.lock with the SQLAlchemy 2.1 range from pyproject.toml

[strickvl]

What this changes

plugins/uv.lock is regenerated so it agrees with the root pyproject.toml again. Only the sqlalchemy entry changes.

• The kitaru package's requires-dist line for the server extra now reads sqlalchemy[asyncio]>=2.0.51,!=2.1.0 (it still said >=2.0.51,<2.1).
• The resolved sqlalchemy moves from 2.0.51 to 2.1.1, the same version the root uv.lock resolves.

Why

#1250 widened the SQLAlchemy range in the root pyproject.toml and updated the root uv.lock, but plugins/uv.lock was not regenerated. Two things followed:

1. uv lock --check fails inside plugins/.
2. Plugin tests in CI ran against SQLAlchemy 2.0.51 while the core tests ran against 2.1.1. CI did not notice because it installs plugins with uv sync --project plugins --frozen --all-packages, and --frozen installs whatever the lock file says without checking it against pyproject.toml.

Reviewer Notes

This took two commands, not one, and the second is the part worth checking.

Plain uv lock only rewrote the stale specifier line. It left the resolved version at 2.0.51, because 2.0.51 still satisfies the new range and uv keeps an existing pin whenever it is still allowed. That alone makes uv lock --check pass but leaves plugin CI on the old SQLAlchemy.

To close the gap I ran uv lock --project plugins --upgrade-package 'sqlalchemy==2.1.1'. I pinned 2.1.1 on purpose: an unpinned upgrade picks 2.1.2, which would put plugins one patch ahead of the version #1250 validated for core. No other package moved (155 packages before and after).

One line in the diff that looks odd but is expected: the greenlet dependency with the long platform_machine marker disappears from the sqlalchemy entry. SQLAlchemy 2.1 no longer installs greenlet by default. Kitaru asks for sqlalchemy[asyncio], and that extra still pulls greenlet in, so it remains in the lock and in the installed environment (verified: greenlet 3.5.4 imports next to sqlalchemy 2.1.1).

If this is wrong, the failure would show up as plugin tests that touch the server's database code breaking under 2.1.

Reproduction

On develop:

cd plugins && uv lock --check

This fails with The lockfile at uv.lock needs to be updated. On this branch the same command passes.

To see the version alignment:

grep -A1 '^name = "sqlalchemy"' uv.lock plugins/uv.lock

Both files should print version = "2.1.1".

To run the plugin tests against the new resolution:

uv sync --project plugins --all-extras --all-groups
uv run --project plugins --no-sync pytest plugins/tests

Expect 2103 passed, 2 skipped.

Local checks run

just check passes. Plugin tests pass (2103 passed, 2 skipped). just test: 4781 passed; the only failures were 6 tests under tests/typescript/, which fail in setup at pnpm --filter @zenml-io/kitaru build because my worktree has no JavaScript install. They do not exercise this change.

No changelog fragment: this is not user-facing.

Not in this PR

Nothing in CI runs uv lock --check for plugins/, so the same drift can happen again the next time a root dependency range changes. #1258 adds that check and is stacked on this PR.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-05T11:10:12.376974Z	732e926	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[AlexejPenner]

🦭