Enforce the requirements/pyproject invariant, and stop pointless floor bumps - #55
Merged
Merged
Conversation
…r bumps requirements.txt has said "Keep in sync with pyproject.toml [project.dependencies]" since it was written, and nothing enforced it. Dependabot then proposed raising tomli>=2.0.1 to >=2.4.1 in requirements.txt alone (#54), which would have left the two manifests disagreeing on the first line it touched -- silently, since installs resolve from pyproject.toml, so the requirements floor has no effect on what a user actually gets. A manual-sync comment is not a control. TestRequirementsMatchPyproject compares the two dependency sets with whitespace and quote noise normalised away, so the environment marker on tomli does not produce a false difference. Verified it bites by simulating #54: it names tomli>=2.4.1 as present only in requirements.txt. A second case asserts the parse is non-empty, so an empty read cannot make the comparison vacuous. The second half is the reason that PR existed at all. Dependabot's pip default versioning-strategy is "increase", which raises a `>=` floor on every upstream release whether or not anything needs it -- proposing churn with no security driver, and dropping support for environments the code runs on perfectly well. increase-if-necessary moves a floor only when the existing constraint genuinely excludes the new version. Security updates still raise floors when they have to.
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.
Closes the root cause behind #54 rather than merging it.
The invariant was a comment, not a control
requirements.txthas always said "Keep in sync with pyproject.toml [project.dependencies]", and nothing checked it. #54 proposed raisingtomli>=2.0.1→>=2.4.1in requirements.txt alone, which would have left the two manifests disagreeing on the first line it touched — and silently, sincepip install pcapperresolves frompyproject.toml, so the requirements floor has no effect on what anyone actually gets.TestRequirementsMatchPyprojectnow compares both dependency sets with whitespace and quote noise normalised away, sotomli's environment marker doesn't read as a false difference. Verified it bites by simulating #54 against the real files:A second case asserts the parse is non-empty, so an empty read can't make the comparison vacuous.
And the reason that PR existed at all
Dependabot's pip default
versioning-strategyisincrease— it raises a>=floor on every upstream release, whether or not anything needs it. That is what generated atomlibump with no security advisory behind it.increase-if-necessarymoves a floor only when the current constraint genuinely excludes the new version; security updates still raise floors when they have to.Lands in
test_packaging.pybeside the version-drift and missing-subpackage guards — same class of defect, invisible from the source tree, caught by an assertion instead of a comment.