chore(deps): use the uv Dependabot ecosystem so uv.lock stays in sync - #3203
Merged
Conversation
The pip ecosystem reads the PEP 621 pins in pyproject.toml but has no concept of uv.lock, so every Python bump it opened updated the pin and left the lockfile resolved to the old version. All five bumps bundled in the previous change carried that drift. Switch the Python entry to the uv ecosystem, which understands both files and updates them together. pyproject.toml and uv.lock are the only Python manifests in the repo (no requirements.txt / setup.py / Pipfile), so nothing the pip ecosystem covered is lost. This replaces pip rather than adding alongside it — running both would open duplicate PRs for the same dependencies. Also group Python updates into a single PR, matching the bun, docker and github-actions entries; pip was the only ecosystem without a group, which is why five separate PRs landed. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
|
There was a problem hiding this comment.
Pull request overview
Updates the repository’s Dependabot configuration to use the native uv ecosystem so that Python dependency updates keep pyproject.toml and uv.lock in sync, preventing recurring lockfile drift.
Changes:
- Switch Dependabot’s Python updater from
piptouvto ensureuv.lockis updated alongsidepyproject.toml. - Add a
pythondependency update group for theuvecosystem to bundle Python updates into a single PR. - Document in-file why
uvis required (lockfile sync rationale).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Fixes the root cause behind the lockfile drift that #3201 had to clean up by hand.
The problem
The Python entry used
package-ecosystem: "pip". The pip ecosystem reads the PEP 621 pins inpyproject.tomlbut has no concept ofuv.lock— so every Python bump it opened updated the pin and left the lockfile resolved to the old version. All five bumps bundled in 3201 carried that drift, and it would have recurred on every future Python bump.Dependabot can't be told to "run
uv lock" — it doesn't execute arbitrary commands. The fix is the nativeuvecosystem, which understandspyproject.tomlanduv.lockand updates them together.Notes on the change
piprather than adding alongside it. Running both would open duplicate PRs for the same dependencies.pyproject.toml+uv.lockare the only Python manifests in the repo — there is norequirements.txt,setup.py,Pipfile, orpoetry.lock.bun,dockerandgithub-actionsentries.pipwas the only ecosystem without a group, which is exactly why five separate PRs landed instead of one.cooldownneeded. That's only recommended to mirror uv'sexclude-newer, which this repo doesn't set.On the strict
==pinsWorth flagging, since there was a known issue (dependabot/dependabot-core#12788) about the uv ecosystem updating
uv.lockbut notpyproject.toml. It was closed as a non-bug: that reporter used>=constraints, so their manifest genuinely needed no change. This repo pins with==, so a bump cannot satisfy the existing constraint and Dependabot must update both files.Validation
Nothing in CI validates this file —
actionlintonly covers.github/workflows/, so a malformed config would fail silently rather than break a check. Verified manually instead:bun,uv,docker,github-actions), each with its group.uvis confirmed present in that schema'spackage-ecosystemenum.The real proof is the next Dependabot run opening a grouped Python PR that touches both
pyproject.tomlanduv.lock— worth a glance when it lands.🤖 Generated with Claude Code