ci: resolve the declared dependency floors on every matrix entry - #30
Merged
Merged
Conversation
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.
Adds the
floorsjob the org standard requires (standard.md §7), following modern-di-fastapi#56, and extends the existing marker set to cover 3.13.What the job found
This repo already carried
pydantic>=2.12; python_version >= '3.14'for exactly this reason — aiogram pulls pydantic, and pydantic-core ships nocp314wheel before 2.12. The marker stopped one interpreter short, and it was not the only dependency with the problem.aiogram>=3.2resolves to aiogram 3.2.0, which pins pydantic 2.5.3 andaiohttp~=3.9.0. On 3.13 neither installs from a wheel:Both are needed — bounding pydantic alone lifts aiogram to a release that still pins
aiohttp~=3.9, so the second error simply replaces the first:pydantic 2.8.1 rather than 2.8: pydantic-core 2.20.0 ships a manylinux
cp313wheel but no macOS arm64 one, and 2.20.1 — pydantic 2.8.1 — is the first that covers both. A floor that holds only on the platform CI happens to run is not a floor.Why the job exists
pytestresolves every dependency at its newest, so the bottom of each declared range ships unexercised. This job resolves direct dependencies at their floors, wheel-only, on every entry of the same matrixpytestuses, and runs the suite against them. Wheel coverage is per interpreter — 3.10 through 3.12 were fine throughout — which is why the job runs on every entry rather than one.--no-build: a floor reachable only by compiling an sdist is not a floor a user installing a wheel can reach.--no-install-projectis mandatory alongside it —--no-buildwould otherwise refuse to build this project too, and the tests import it from the checkout.The dev-group floors
uv sync --resolution lowest-directtreats an unbounded name in[dependency-groups]as "any version" and resolves it to that project's first-ever release. These are lower bounds on the test harness only; none constrainsaiogram, which the job still installs at 3.2.0 on 3.10–3.12. The resolved-newest path is unchanged.Verification
Run locally on all six interpreters at the floors:
aiogram==3.2.0on 3.10–3.12, lifted on 3.13–3.14t, 27 passed on each. Resolved-newest path re-checked withjust install && just lint-ci && just test-ci.