build(deps-dev): update mypy requirement from <2.4,>=2.3 to >=2.3.1,<2.4 - #212
Closed
dependabot[bot] wants to merge 1 commit into
Closed
build(deps-dev): update mypy requirement from <2.4,>=2.3 to >=2.3.1,<2.4#212dependabot[bot] wants to merge 1 commit into
dependabot[bot] wants to merge 1 commit into
Conversation
Updates the requirements on [mypy](https://github.com/python/mypy) to permit the latest version. - [Changelog](https://github.com/python/mypy/blob/master/CHANGELOG.md) - [Commits](python/mypy@v2.3.0...v2.3.1) --- updated-dependencies: - dependency-name: mypy dependency-version: 2.3.1 dependency-type: direct:development ... Signed-off-by: dependabot[bot] <support@github.com>
This was referenced Sep 8, 2026
Jason-Vaughan
added a commit
that referenced
this pull request
Sep 9, 2026
…oor raises (#221) * Raise the setuptools build floor past two advisories; decline four floor raises Dependabot proposed five pip floor raises (#208-#212). One is taken, four are declined, and the reasons matter more than the diff. `versioning-strategy: increase` proposes a floor raise for every in-range release, so the pull request exists whether or not the raise buys anything. Checked against GitHub's advisory database rather than assumed: no advisory touches httpx above 0.23.0 or PyYAML above 5.4, and the floors here are already 0.27 and 6.0. Raising those would narrow what a user may install and incur a breaking-change announcement under docs/design/deprecation-policy.md in exchange for nothing, so both stand unchanged. `setuptools >= 68` is the opposite case. It permits versions carrying a HIGH advisory (fixed in 78.1.1) and a MODERATE one (fixed in 83.0.0), and it is not the dev dependency its Dependabot label suggests — it is `build-system.requires`. Now `>= 84, < 85`. This owes no announcement: a build requirement is resolved when building from an sdist, never by someone installing the wheel, and the deprecation policy's floor clause governs what a user may install. The inherited triage had this backwards — it treated the two runtime bumps as the consequential pair and setuptools as routine dev churn with a big number. The one that looked like churn was the only one fixing a vulnerability. The structural finding outlives the bumps: DependencyBoundTest read `project.dependencies` and the extras and stopped there, so `build-system.requires` was the one table in pyproject.toml held to no rule — exactly where the unbounded, vulnerable floor was sitting. Requirement discovery now includes it, and `wheel` gained a bound in the same pass. Verified by mutation: restoring `["setuptools>=68", "wheel"]` fails the bound test twice, each failure naming `build-system.requires`. The ceiling's cost is real and recorded at the code site: setuptools ships majors every few weeks, so `< 85` will produce frequent pull requests. Kept because the upper-bound rule has no build-requirement exemption and the weekly canary resolves this fresh on every run. The dev-extra floors moved to `ruff >= 0.16.6` and `mypy >= 2.3.1` — those bind contributors rather than installs and owe nothing. Suite 805 green (788 passed, 17 skipped). * Correct the canary claim, pin the new coverage, and record the build-requirement ruling Critic rev-20260909T030030Z-d21a5720: 0 blocking, 9 warning, 12 note. Three findings were real defects rather than taste, and are fixed here. THE COMMENT WAS WRONG, which is the one that matters. It justified the `< 85` ceiling partly on the weekly CI canary catching a setuptools major that breaks the build. With `< 85` in force an isolated build can only ever resolve 84.x, so a breaking major is precisely the thing the canary cannot see — what catches it is CI on the Dependabot pull request that raises the cap. That is the model .github/dependabot.yml and docs/design/nonfunctional-requirements.md already describe, so the comment contradicted a ratified norm while sitting two files away from it. The clause is deleted; the first ground — the upper-bound rule has no exemption for build requirements — carries the decision alone. Same shape as the defect #146 fixed: guard a door, then write down an invariant that is false. THE NEW COVERAGE WAS UNPINNED. test_every_declared_dependency_carries_an_upper_bound iterates whatever _all_requirements hands it, so deleting the build-system lines leaves it passing over a smaller set — silently restoring the exact defect this change exists to fix. A second test now asserts the discovered *set* contains build-system.requires. Verified by mutation: removing those lines fails it with the sources it did find. THE DESIGN DOCS STILL ENUMERATED THE OLD SET. deprecation-policy.md and nonfunctional-requirements.md both described the packaging test as asserting over "project.dependencies and every extra". Worse, the load-bearing new ruling lived only in a code comment and the changelog — and deprecation-policy.md is the artifact that comment cites. Both now record it: a build requirement carries the ceiling rule and is exempt from the announcement rule, the halves separate because an unbounded build requirement still lets a major land in an sdist build unannounced, while raising its floor changes no user's install. Also: GHSA and CVE ids for both advisories rather than severities alone (GHSA-5rjg-fvgr-3xxf / CVE-2025-47273, GHSA-h35f-9h28-mq5c / CVE-2026-59890 — the latter an sdist-build defect, which is the operation this requirement governs); and an honest note that 83.0.0 is the security minimum while 84 is merely the current major, since the commit this amends argues a floor raise is a cost until justified. Dropping `wheel` rather than bounding it is filed as #222. Suite 806 green (789 passed, 17 skipped). * Unanchor the setuptools rationale from one Dependabot batch The comment said this was "the only floor raise of the five Dependabot proposed that fixes anything". "The five" names one September 2026 batch, and permanent prose beside a requirement will not be re-explained on the next one — a reader in six batches' time finds a sentence about a set they cannot reconstruct. Replaced with the general rule the sentence was an instance of: a build requirement carries the ceiling and is exempt from the announcement, which is what let this floor move when a runtime floor raise could not. The decision about that specific batch, with its PR links, is already in CHANGELOG.md, which is where a dated record belongs. Critic rev-20260909T030030Z-d21a5720 R-11.
Author
|
Looks like mypy is up-to-date now, so this is no longer needed. |
Owner
|
Superseded by #221, merged as This raise has shipped — the All five pip proposals were triaged as one decision. Two were declined (#209, #210) — full reasoning in #221. Closing as superseded — thanks, Dependabot. |
This was referenced Sep 9, 2026
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.
Updates the requirements on mypy to permit the latest version.
Changelog
Sourced from mypy's changelog.
... (truncated)
Commits
d642c44Bump version to 2.3.1a392429[mypyc] Fix crash on double yielding Iterators (#21826)4843e77[mypyc] Fixdefault_factoryfor inherited dataclass (#21785)14f5df9[mypyc] Clear coroutine env on coroutine completion (#21734)6dfa06dFix crash when unpacking return value from overload (#21830)a385746Bump version to 2.3.1+devDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)