ci: stop TestPyPI supplying third-party dependencies - #38
Merged
Conversation
The v0.0.2 release failed after TestPyPI had already published: the install-back-out check died on `Failed to build 'fastapi'` / `FileNotFoundError: DESCRIPTION.txt`. Nothing to do with our packages. TestPyPI is a sandbox anyone may upload to, so it carries junk copies of common names. Its `fastapi` is a decade-old placeholder whose sdist cannot be built -- and it out-numbers the real one, so pip prefers it. The old flags made TestPyPI the PRIMARY index, which invited that, and the comment above them claimed the opposite of what the code did. Swapping the indexes alone does not fix it, which I checked before committing: the junk version is higher, so it wins from either position. It takes both flags. Real PyPI primary, so dependencies come from where they live and TestPyPI is consulted only for names PyPI does not have -- exactly our six at an unreleased version. Plus --only-binary :all:, which refuses sdists: the junk is source-only, every real dependency ships wheels, and ours are pure-Python wheels. Verified against the 0.0.2 that is already on TestPyPI, not a simulation: the old flags reproduce the fastapi failure, the new ones install all six at 0.0.2, and the starter shape (no observability adapter) runs the quickstart -- `echo: hi there`. So the artifact that is already published is good; only the gate in front of it was broken. PyPI never ran, so 0.0.2 is still unpublished there and the tag can move.
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.
The
v0.0.2release failed at the install-back-out gate, after TestPyPI had publishedand before PyPI ran — so 0.0.2 is still unpublished on PyPI and nothing bad shipped.
Nothing to do with our packages. TestPyPI is a sandbox anyone may upload to, and its
fastapiis a decade-old placeholder whose sdist cannot be built. It also out-numbers thereal one, so pip prefers it. The old flags made TestPyPI the primary index, and the
comment above them described the opposite of what the code did.
Swapping the indexes is not enough — I checked before committing; the junk version is
higher, so it wins from either position. It needs both:
--index-url https://pypi.org/simple/— dependencies come from where they live; TestPyPIis consulted only for names PyPI lacks, which is exactly our six at an unreleased version
--only-binary :all:— refuses sdists; the junk is source-only, real dependencies shipwheels, ours are pure-Python wheels
Verified against the real thing, not a simulation
Against the
0.0.2already on TestPyPI:fastapifailure0.0.2echo: hi thereThe published artifact is fine — only the gate in front of it was broken.
After merge,
v0.0.2moves to this commit and re-runs. TestPyPI already has 0.0.2;skip-existing: truecovers the re-upload.