ci: drop committed lockfile, keep mypy <2.1#135
Closed
FBumann wants to merge 1 commit into
Closed
Conversation
Revert the lockfile machinery from #128 while keeping the actual fix. The mypy<2.1 bound in pyproject is what unbroke the Type check job; the committed uv.lock + --frozen CI were extra robustness against transitive drift that isn't worth the relock workflow for a library this size. CI resolves fresh against the pyproject ranges again, and dependabot returns to the pip ecosystem (bumps pyproject, not a lock). If a transitive dep ever breaks CI, bound it in the dev group (or via [tool.uv] constraint-dependencies) — dev-only, never ships downstream. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Documentation build overview
|
Contributor
Author
|
Closing — the revert proved the lockfile is doing real work. Dropping it re-breaks type-check: a fresh resolve pulls numpy 2.5.0, whose PEP 695 stubs mypy rejects under python_version=3.11 (even at mypy 2.0.0, so the mypy<2.1 bound alone isn't enough). The committed uv.lock pins numpy 2.4.6 and keeps CI green. Keeping #128's lockfile setup as-is. |
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
1 participant
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.
Reverts the lockfile machinery added in #128 while keeping the actual fix.
A pure
git revertof #128 would also dropmypy<2.1and re-break the Type check job, so this is a targeted revert.What changes
uv.lockand re-ignore it — CI resolves fresh against thepyproject.tomlranges again.--frozenfrom theuv syncsteps inci.yaml/docs.yaml.uv→pipecosystem (bumps pyproject constraints, not a lock). Kept monthly.What stays
mypy<2.1in the dev group — this is what unbroke type-check (mypy 2.1.0 errors on numpy's PEP 695 stub underpython_version=3.11).Rationale
The committed lock +
--frozenwere robustness against transitive drift, but for a library this small that's not worth the relock workflow and large lock diffs. If a transitive dep ever breaks CI, bound it in the dev group (or[tool.uv] constraint-dependencies) — dev-only, never ships downstream. Runtime deps remain loose ranges;nightly.yamlstill floats--resolution lowest/highest.Verified
uv sync --group dev(no frozen) +uv run mypy src/pytest_benchmem tests→ Success: no issues found in 25 source files.🤖 Generated with Claude Code