chore: regenerate uv.lock to match pyproject's bench extra

[mattmillerai]

ELI-5

pyproject.toml says the bench extra needs anthropic, but uv.lock never got the memo — anthropic isn't in the lock at all. So uv thinks the lock is wrong and silently rewrites it every time anyone runs uv run, uv sync, or uv lock in any worktree. Then the next git commit -a / git add . sweeps those ~287 lines into whatever unrelated PR you happened to be working on.

This runs uv lock once and commits the result, so the lockfile matches pyproject.toml and uv stops dirtying the tree.

Problem

uv lock --check fails on main today:

$ uv lock --check
Resolved 80 packages in 24ms
The lockfile at `uv.lock` needs to be updated, but `--check` was provided.

pyproject.toml:59 declares optional-dependencies.bench = [ "anthropic>=0.40" ] (added with the bench runner in #490), but the lock was never regenerated — anthropic is entirely absent from it.

This is not cosmetic. It already bit #533: commit ee4ccdd accidentally committed exactly this delta into an unrelated 2-file tomlkit fix, contradicting that PR's own description. It was reverted in 623fa5f, but the trap stayed armed and will keep catching anyone who runs a uv command before committing.

Fix

uv lock, run on a clean checkout of main, committed alone with nothing else in the diff.

Verification

• uv lock --check now exits 0 (was exit 1).
• Only uv.lock changes — 1 file, +285/-2.
• Additions are exactly the bench extra's tree: anthropic, plus its transitive deps annotated-types, docstring-parser, jiter, pydantic, pydantic-core, typing-inspection — and the bench entry in provides-extras.
• Nothing is removed and no existing version pin moves (zero -name = / -version = lines in the diff).
• Idempotent — re-running uv lock produces a byte-identical file.
• Repo checks green: ruff check (all passed), ruff format --check (235 files formatted), pytest (2573 passed, 37 skipped).
• End-to-end: a full uv run --extra dev cycle now leaves uv.lock untouched and the tree clean — previously it would have rewritten it. The footgun is disarmed.

One incidental change, and why it's safe

Beyond the expected delta, uv also simplified one marker on a transitive edge:

 name = "exceptiongroup"
 dependencies = [
-    { name = "typing-extensions", marker = "python_full_version < '3.13'" },
+    { name = "typing-extensions" },
 ]

This is uv normalizing away a now-redundant marker: anthropic requires typing-extensions unconditionally, so the version-gated edge no longer constrains anything. It is not a version bump (exceptiongroup stays 1.3.0).

It is provably inert. Exporting the resolved install set from the old lock and the new lock gives a byte-identical result on Python 3.10, 3.12, 3.13 and 3.14 — including 3.13+, which is exactly where that marker would have mattered. Nothing that installs today installs differently.

Risk

Minimal. CI never reads uv.lock — every workflow installs via pip install -e . (build-and-test, pytest, test-mac, test-windows, run-on-gpu). The benefit is purely that uv commands stop dirtying the working tree.

Noted for follow-up (deliberately not in this PR)

While verifying, I found a separate, pre-existing staleness: pylock.toml (tracked, regenerated by the uv-export pre-commit hook) is also out of date — regenerating it adds backoff, distro, and posthog.

I confirmed it is independent of this change: regenerating pylock.toml on pristine main produces a file identical to regenerating it on this branch (same checksum), and its delta involves runtime deps, not anthropic. So this PR neither causes nor worsens it.

I left it out on purpose — folding unrelated churn into this diff would recreate the exact problem this PR removes. It's the same class of footgun and worth its own one-line fix.

[coderabbitai]

Important

Review skipped

Review was skipped due to path filters

⛔ Files ignored due to path filters (1)

• uv.lock is excluded by !**/*.lock

CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including **/dist/** will override the default block on the dist directory, by removing the pattern from both the lists.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 65980ec1-8630-4616-a7b9-8c280e1b828a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch matt/be-3308-regenerate-uv-lock

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch matt/be-3308-regenerate-uv-lock

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

🔍 Cursor Review — Consolidated panel

Triggered by @mattmillerai.

✅ No high-signal findings.

Panel: 6/8 reviewers contributed findings.

Reviewers that did not contribute: kimi-k2.5:adversarial (empty), kimi-k2.5:edge-case (empty)

[mattmillerai]

The failing build check is not caused by this PR — it is a repo-wide breakage from a third-party release that landed today, and main is red with it too.

Root cause: tomlkit 0.15.1 (released 2026-07-17) added validation to Item.comment() that rejects comments containing line breaks:

ValueError: Comment cannot contain line breaks   # tomlkit/items.py:504

comfy_cli/registry/config_parser.py passes triple-quoted multi-line strings to .comment() in two places — config_parser.py:75 (the [tool.comfy].includes hint) and config_parser.py:250 (the commented-out classifiers block). Both now raise, failing 9 tests (8 in test_config_parser.py, 1 in test_node_init.py). Those call sites are byte-identical on pristine main and are untouched by this diff, which is uv.lock-only (1 file, +285/-2).

tomlkit is unpinned in pyproject.toml:49, and CI installs via pip install -e ., so it resolves the newest release. Bisected locally:

tomlkit	result
0.13.3	81 passed
0.14.0	81 passed
0.15.0	81 passed
0.15.1	8 failed, 73 passed

Worth noting this is the mirror image of the bug this PR fixes: uv-based local runs still pass because uv.lock pins tomlkit 0.13.3 — the break is only visible through the pip path CI uses.

This PRs own claim still verifies: uv lock --check exits 0 on this branch and fails on pristine main.

I have deliberately not fixed the tomlkit issue here. This PR is lockfile-only by design — its entire purpose is to stop unrelated churn being swept into unrelated diffs (the #533 mistake). Folding a config_parser.py fix in would contradict its own description and recreate the exact footgun it removes. It also blocks the whole repo, so it deserves its own fast-tracked PR rather than being buried in a chore diff.

Filed as a follow-up (fix the two .comment() call sites to emit per-line comments, and add an upper-bound pin for tomlkit so an unpinned upgrade cant redden CI repo-wide again). This PR is blocked on that fix landing first, after which it should go green with no changes.

[mattmillerai]

Correction to my comment above: the tomlkit fix is already open, so no new follow-up is needed. Two PRs already cover it — #536 (fix(registry): emit pyproject hints as standalone comments for tomlkit 0.15, which also pins tomlkit in pyproject.toml) and #533 (fix(registry): emit pyproject hint blocks as single-line tomlkit comments). They are duplicates of each other; one should land and the other close. This PR is blocked until whichever one merges, then it should go green with no changes here.

Separately, and worth a maintainer decision: this PR appears to be one of three open PRs doing the same uv.lock regeneration — #543 (this one), #541 (chore: refresh the stale uv.lock so uv run stops dirtying working trees), and #534 (build(deps): re-sync uv.lock with the pyproject bench extra (BE-3291)). All three are uv.lock-only. Only one should land; the other two should be closed as duplicates. I have not closed anything — flagging for a human to pick the keeper.