fix(deps): stop Dependabot ratcheting dependency floors#2121
Merged
Conversation
Dependabot's default uv versioning strategy raises the lower bound in pyproject.toml to the latest release on every bump. For a library this is wrong: it forces the floor upward with no compatibility benefit and breaks downstream consumers that pin older versions. This surfaced with aiohttp: #2115 bumped the floor 3.10.3 -> 3.14.0, which conflicts with Home Assistant core's aiohttp==3.13.5 pin, making pyoverkiz uninstallable there. boto3 was ratcheted the same way across #2065/#2080/#2117 (1.18.59 -> 1.43.22), though as an optional nexity dep it had no visible impact. - Restore aiohttp floor to >=3.10.3 and boto3 floor to >=1.18.59 - Set versioning-strategy: lockfile-only on the uv ecosystem so Dependabot updates uv.lock (keeping CI on latest) without touching the abstract lower bounds in pyproject.toml uv.lock still resolves both to their latest versions; only the recorded specifiers change.
Contributor
There was a problem hiding this comment.
Pull request overview
This PR aims to prevent Dependabot (uv ecosystem) from “ratcheting” the library’s declared dependency lower bounds in pyproject.toml, restoring wider compatibility for downstream consumers while keeping uv.lock on current resolved versions.
Changes:
- Lower
aiohttp’s declared minimum back to>=3.10.3andboto3(optionalnexity) back to>=1.18.59. - Mirror those restored specifiers in
uv.lock’spackage.metadata.requires-dist. - Add
versioning-strategy: lockfile-onlyto theuventry in.github/dependabot.yml.
Reviewed changes
Copilot reviewed 2 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
pyproject.toml |
Restores dependency lower bounds for aiohttp and optional boto3 to widen downstream compatibility. |
uv.lock |
Updates requires-dist metadata to match the restored dependency specifiers while still resolving latest versions. |
.github/dependabot.yml |
Attempts to configure Dependabot to update only uv.lock and avoid changing pyproject.toml ranges. |
💡 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.
Problem
Dependabot's default
uvversioning strategy raises the lower bound inpyproject.tomlto the latest release on every bump. For a library this is the wrong behavior — it ratchets our floors upward with no compatibility benefit and breaks downstream consumers that pin older versions.This surfaced with aiohttp: #2115 bumped the floor
>=3.10.3→>=3.14.0, which conflicts with Home Assistant core'saiohttp==3.13.5pin, making pyoverkiz uninstallable there.Auditing the rest of the deps, boto3 had been ratcheted the same way across #2065 / #2080 / #2117 (
>=1.18.59→>=1.43.22), though as an optionalnexitydependency it had no visible impact. The remaining floors (backoff,attrs,cattrs,warrant-lite) were untouched by Dependabot and already have healthy wide ranges.Changes
aiohttpfloor to>=3.10.3(was the floor before Bump aiohttp from 3.13.5 to 3.14.0 #2115)boto3floor to>=1.18.59(was the floor before Bump boto3 from 1.43.4 to 1.43.14 #2065)versioning-strategy: lockfile-onlyon theuvecosystem in.github/dependabot.yml, so Dependabot updatesuv.lock(keeping CI on the latest versions) without touching the abstract lower bounds inpyproject.tomluv.lockstill resolves both to their latest versions (aiohttp 3.14.0, boto3 1.43.22) — only the recorded specifiers change.Why this matters now
Without this, the next Dependabot run would re-raise the aiohttp floor straight back to 3.14 and reintroduce the HA core conflict.
lockfile-onlyis the correct long-term policy for a library.