ci(release): publish to PyPI, which README has been promising all along - #81
Merged
Merged
Conversation
README.md's install line is `pip install liminate`, and both liminate-receipts and liminate-contract-inheritance depend on the PyPI distribution. PyPI is a real release channel for this project and it was never in this workflow — the workflow builds signed binaries and attaches them to a GitHub Release, and that is all it has ever done. Through 0.18.1 someone uploaded to PyPI by hand, so the binaries and the package could drift apart with nothing to notice. 0.18.2 is where that showed: it shipped three signed binaries while `pip install liminate` stayed on 0.18.1 and on four missing behaviour fixes, one of which stops `includes` from silently emptying a list. Authentication is trusted publishing (OIDC), matching what the TypeScript validator moved to this week: PyPI mints a one-time credential for this workflow, nothing is stored, nothing expires. No GitHub environment gate — the fewer fields that have to match between here and the PyPI form, the fewer ways a release fails at the last step. Also declares [build-system] and package discovery. There was no such table through 0.18.1: every build worked because pip supplies setuptools when a project names no backend and setuptools auto-discovers a src/ layout. Both are conveniences rather than guarantees, and a release build should not rest on either. Verified locally — sdist and wheel build clean, 21 modules and the packs data present in the wheel. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E6qcDj1e1dEYvc8jLnpGZy
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.
README.mdline 54 ispip install liminate, and bothliminate-receiptsandliminate-contract-inheritancedepend on the PyPI distribution. PyPI is a real release channel for this project and it was never in this workflow — the workflow builds signed binaries and attaches them to a GitHub Release, and that is all it has ever done.Through 0.18.1 someone uploaded by hand, so the binaries and the package could drift apart with nothing to notice. 0.18.2 is where it showed: three signed binaries shipped while
pip install liminatestayed on 0.18.1 — and on four missing behaviour fixes, one of which stopsincludesfrom validating clean and silently emptying a list.What this adds
A
publish-pypijob on the same tag trigger, using trusted publishing (OIDC) — matching what@liminate/ts-validatormoved to this week. PyPI mints a one-time credential for this workflow; nothing is stored, nothing expires, nothing to rotate in 90 days.No GitHub environment gate. It is optional on PyPI's side, and every field that has to match between this file and the PyPI form is another way a release fails at the last step.
The job verifies the tag against
pyproject.tomlbefore building, same guard the validator's release has.Also:
[build-system]declaredThere was no such table through 0.18.1. Every build worked because pip supplies setuptools when a project names no backend, and setuptools auto-discovers a
src/layout. Both are conveniences, not guarantees, and a release build should not rest on either.Verified locally:
python -m buildproducesliminate-0.18.2.tar.gzandliminate-0.18.2-py3-none-any.whl, with 21 modules and thepacks/data present in the wheel.The trusted publisher must exist before this workflow runs. Configuring it does not disable manual uploads, so doing it first is safe.
pypi.org →
liminate→ Manage → Publishing → Add a new GitHub publisher:rmichaelthomasliminaterelease.ymlThen re-push the
v0.18.2tag to run the workflow with this job in it. Nothing was published to PyPI under 0.18.2, so no version number is burned.🤖 Generated with Claude Code
https://claude.ai/code/session_01E6qcDj1e1dEYvc8jLnpGZy