chore(wren-core-py): sync wren-core-py uv.lock on release#2383
Conversation
The wren-core-py release PR bumps pyproject.toml but leaves uv.lock pinned to the old version, so every CI job fails at `uv sync --locked`. Mirror the core/wren config to update uv.lock via jsonpath alongside the version bump. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
WalkthroughIn ChangesRelease-Please Config: wren-core-py uv.lock version tracking
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Possibly related PRs
Suggested labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Why
The
wren-core-pyrelease PR (#2376) fails CI on every job at the install step:release-please bumps
core/wren-core-py/pyproject.toml(0.7.0→0.7.1) but never updatescore/wren-core-py/uv.lock, which keepswren-core-pypinned at the old version. Sinceuv.lockrecords the project's own version (source = { editable = "." }), it goes stale the moment the version bumps, anduv sync --lockedrefuses to run — blocking Core Python CI and all Wren SDK CI jobs (which build the wren-core-py wheel first).Fix
Add a
uv.lockextra-filesentry forcore/wren-core-py, mirroring the existingcore/wrenconfig so the lockfile version is updated via jsonpath alongside thepyproject.toml/Cargo.tomlbump.Once merged, release-please will regenerate the open release PR (#2376) with the lockfile change included, turning CI green.
🤖 Generated with Claude Code
Summary by CodeRabbit