setuptools 84, twine range, and the pnpm action pin - #365
Merged
Conversation
… commit SHA Supersedes #346, #347 and #357. Grouped because all three are build-side and all three are proven by one command, make release-artifacts, which double-builds under SOURCE_DATE_EPOCH, normalizes both sdists, compares every artifact against its rebuild, runs twine check, writes checksums and smoke-tests the real wheel. setuptools 83 to 84 is the only bump here that could change what gets published, so it was verified rather than assumed. The built wheel records "Generator: setuptools (84.0.0)", confirming the new backend actually ran under build isolation rather than a cached 83, and Metadata-Version stays 2.4. Release check, normalization, twine check and both artifact smokes all pass. The twine range widens to <8.0, and twine 7.0.0 exists as of 2026-07-27, so this admits it immediately rather than pre-authorizing something hypothetical. It was therefore actually exercised: twine 7.0.0 was installed in a throwaway venv and run against these artifacts. It is byte-for-byte identical to 6.2.0 in outcome, both exiting 0 on the wheel and sdist. Twine 7's only removal is metadata 2.0 support, which was never standardised and which this project does not emit. The pnpm/action-setup change is a no-op and worth recording as such so nobody re-litigates it. The old pin f40ffcd9 is the annotated tag object for v4, not a commit; dereferencing it gives b906affc, which is exactly the new pin. The workflows already execute this code. Dependabot is only converting a tag-object-SHA pin into the equivalent commit-SHA pin, which is the conventional auditable form and the one supply-chain scanners resolve. Noted while gating, not fixed here because it is pre-existing and unrelated: make release-artifacts is not idempotent. Line 129 runs twine check over the whole dist directory and line 130 then writes SHA256SUMS into it, so a second run without clearing dist fails, since twine exits 1 on a file it cannot parse as a distribution. Both twine 6 and 7 behave identically, so this is not a consequence of widening the range. Verified: 4544 unit passed, 2 skipped. make release-artifacts green end to end.
This was referenced Aug 14, 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
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.
Supersedes #346, #347, #357. Close those once this lands.
Grouped because all three are build-side and all three are proven by one command:
make release-artifacts.setuptools 83 → 84, the only one that could change published bytes
Verified rather than assumed. The built wheel records:
So the new backend genuinely ran under build isolation rather than a cached 83, and the metadata version is unchanged. Normalization, byte-reproducibility compare,
twine check, release check and both artifact smokes all pass.twine
<7.0→<8.0, and twine 7 actually existstwine 7.0.0 was published 2026-07-27, so this admits it immediately rather than pre-authorizing something hypothetical. The local venv only resolved 6.2.0 because the current pin was holding it there, which means the Makefile's
twine checkwas not exercising 7.So I installed twine 7.0.0 in a throwaway venv and ran it against these artifacts. Identical outcome to 6.2.0, both exit 0 on the wheel and sdist. Twine 7's only removal is metadata 2.0 support, never standardised and not emitted here.
pnpm/action-setup is a no-op
Recording this so nobody re-litigates it. The old pin
f40ffcd9is the annotated tag object forv4, not a commit. Dereferencing givesb906affc, which is exactly the new pin. The workflows already run this code. Dependabot is converting a tag-object-SHA pin into the equivalent commit-SHA pin, which is the conventional auditable form.Separately: this repo pins
pnpm/action-setupat v4 while upstream is at v6. That is a real upgrade to schedule deliberately, not something to smuggle in here.Pre-existing footgun found while gating, not fixed here
make release-artifactsis not idempotent. Line 129 runstwine check $(DIST_DIR)/*and line 130 then writesSHA256SUMSinto that directory, so a second run without clearingdist/fails: twine exits 1 on a file it cannot parse as a distribution. Both twine 6 and 7 behave identically, so this is not caused by widening the range. Worth a separate fix.Verification
4544 unit passed, 2 skipped.
make release-artifactsgreen end to end.