build(deps): re-sync uv.lock with the pyproject bench extra (BE-3291)

[mattmillerai]

ELI-5

pyproject.toml says "the bench extra needs the anthropic package." uv.lock — the file that pins exact versions so everyone installs the same thing — never got the memo. This PR runs uv lock so the two agree again. Nothing about the normal install changes: anthropic is still optional, and you only get it if you ask for --extra bench.

What & why

optional-dependencies.bench = [ "anthropic>=0.40" ] landed with the BE-2302 arm-B bench runner, but uv.lock was never regenerated, so the lockfile was out of sync with the manifest and a --locked / --frozen workflow could not resolve reproducibly.

Verified on pristine origin/main (red baseline):

$ uv lock --check
The lockfile at `uv.lock` needs to be updated, but `--check` was provided.

$ uv sync --extra bench --locked
The lockfile at `uv.lock` needs to be updated, but `--locked` was provided.

Both pass on this branch.

This is not a fire. No workflow consumes uv.lock today (the Windows job uses pip install -e .; only ci-cursor-review.yml references it, as a path exclusion). This is a correctness/reproducibility cleanup.

The diff

uv.lock is the only changed file (285 insertions, 2 deletions). It adds anthropic plus its transitive deps — annotated-types, docstring-parser, jiter, pydantic, pydantic-core, typing-inspection — exactly the set the ticket predicted.

It is byte-for-byte identical to the re-lock that PR #522 carried accidentally in 6bc9dd9, which is an independent reproduction of the same output.

Two non-additive lines, both benign:

1. provides-extras = ["dev", "preview"] → ["bench", "dev", "preview"] — this is the manifest sync.
2. exceptiongroup's dep on typing-extensions loses its python_full_version < '3.13' marker. Inert marker simplification, unrelated to the bench extra. Every edge into exceptiongroup in the lock is already gated on python_full_version < '3.11', and upstream's published metadata requires typing-extensions>=4.6.0; python_version < "3.13" — so wherever exceptiongroup is installed at all, the dropped marker was trivially true. (typing-extensions>=4.7 is an unconditional root dep regardless.)

No existing package version changed — the only version = lines in the diff are the 7 newly-added packages.

Verification

• uv lock --check — passes.
• uv sync --extra bench --locked — succeeds; installs anthropic 0.117.0, pydantic, jiter.
• uv sync --locked (default, no extras) — removes them again; anthropic count in the base install is 0. Both directions checked, so anthropic is provably still optional and not pulled into the base dependency set.
• import comfy_cli and comfy --help — both fine.
• pytest — 2573 passed, 37 skipped.
• ruff format --check — clean (235 files).
• Lockfile stability against the pinned toolchain: .pre-commit-config.yaml pins uv-pre-commit at 0.8.5 while this was locked with local uv 0.11.26, so I checked for churn ping-pong: uvx uv@0.8.5 lock reproduces this lockfile byte-for-byte and changes nothing. The pre-commit hook will not rewrite it.

Judgment calls & things deliberately left out

• ruff check . reports 14 pre-existing UP038 errors (e.g. comfy_cli/cloud/oauth.py) under the lock's ruff 0.12.7. These are identical on pristine origin/main and untouched by this PR (which changes no Python). Not fixed here — pre-commit pins ruff 0.15.15, so this is a local-toolchain artifact rather than a CI failure.
• pylock.toml is also stale — left alone, worth a follow-up. pylock.toml is generated from uv.lock by the uv-export pre-commit hook. Regenerating it with the pinned uv 0.8.5 yields a 50-insertion/29-deletion diff that adds backoff and others. I confirmed this is pre-existing on main and independent of BE-3291: the identical diff appears on a pristine origin/main worktree, backoff is already in main's uv.lock, and this PR's diff never touches it. Regenerating it here would have polluted an otherwise surgical lockfile diff — the same mistake refactor(workflow): re-home API-workflow validate under comfy workflow validate (BE-3000) #522 made in reverse. Filing it separately is the honest move.
• No CI enforcement added. Nothing stops uv.lock drifting stale again; a uv lock --check CI step would. That's a scope add the ticket explicitly doesn't ask for, so it's a candidate follow-up rather than part of this diff.

Risk

Lockfile-only, additive, gated behind an opt-in extra, with the default install proven unaffected in both directions. The negative-claim/capability-denial check does not apply here — this PR restores a capability (uv sync --extra bench --locked) rather than denying one.

[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: 45f7a57f-7b95-4235-894f-17b6cf795bf7

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-3291-relock-bench-extra

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch matt/be-3291-relock-bench-extra

---

_{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]

Heads-up on a scope note: this PR was red on build, but not because of the lock re-sync.

tomlkit 0.15.1 was released today (2026-07-17 01:48 UTC) and tightened the trailing-comment setter to reject line breaks (upstream #449 — they treat it as a fix, since a trailing comment sits after a value on one line and multi-line content was never valid TOML; tomlkit just did not validate it before). comfy_cli/registry/config_parser.py smuggles multi-line commented-out hint blocks through that setter at two call sites (:75 and :250), so every generated pyproject.toml now raises ValueError: Comment cannot contain line breaks — 9 tests fail.

This hits main too: pytest.yml installs with pip install -e ., so it ignores uv.lock entirely and resolves tomlkit straight from PyPI. Nothing in this PR could have caused or prevented it.

I added the minimal unblock here — capping tomlkit<0.15.1 — since this is already the deps PR and it gets the tree installable again. Verified by bisecting the dependency:

tomlkit	test_config_parser.py
0.14.0	81 passed
0.15.0	81 passed
0.15.1	8 failed, 73 passed

Full suite CI-style (pip install -e . in a clean env, resolves 0.15.0): 2573 passed, 37 skipped — was 9 failed / 2565 passed. ruff check + ruff format --diff clean on CI's pinned 0.15.15. No package in the tree depends on tomlkit, so the cap introduces no resolution conflict internally.

I deliberately did not restructure the hint blocks here. That is the real fix, but it changes the generated pyproject.toml that comfy node init writes for users (where the hint lines land, exact formatting) and the tests assert on that output — a user-facing output decision that deserves its own PR, not a lock re-sync. Filed as a follow-up to do the restructure and lift the cap, which should happen promptly: tomlkit is a common library and an upper bound can conflict for users whose environment needs >=0.15.1.

No review threads were outstanding — CodeRabbit skipped (uv.lock is path-filtered) and all cursor-review panels passed.

[mattmillerai]

Correction to my previous comment — I have reverted the tomlkit<0.15.1 cap I pushed, and this PR is back to a pure uv.lock re-sync.

The root-cause diagnosis stands: tomlkit 0.15.1 (released today) made the trailing-comment setter reject line breaks (upstream #449), breaking the multi-line hint blocks at config_parser.py:75 and :250. That fails 9 tests on main and every open PR, because pytest.yml installs via pip install -e . and ignores uv.lock. None of it is caused by this PR.

What I missed the first time: #533 and #536 are already fixing exactly this, properly. #533 is green, non-draft, and touches only config_parser.py + tests. I verified its branch empirically against the tomlkit that breaks main:

branch	tomlkit 0.13.3	tomlkit 0.15.1
main / this PR	pass	8 failed
#533	85 passed	87 passed

So my cap was redundant, and worse than redundant: once #533 lands, a <0.15.1 cap sitting in pyproject.toml would keep users off 0.15.1 anyway — silently negating the point of #533 — and would linger until someone remembered to remove it. Painting this PR green with a band-aid that outlives its own justification is not worth it, so I dropped the commit (force-with-lease over my own unreviewed commit; no one else had pushed).

Status: this PR needs no changes of its own. Its build failure is entirely the tomlkit breakage and will clear once #533 merges and this rebases onto main. It is a one-line lock re-sync with no urgency, so waiting on the real fix is the right sequencing. I have filed no follow-up, since #533/#536 already cover the work.