You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
release(2.5.46): PyPI publish stranded at 1/5 wheels — project hit the 10 GB storage limit #1756
Status: 2.5.46 is published on GitHub Releases but only 1 of 5 wheels reached PyPI. main release path is blocked: any further upload to the project fails until storage headroom exists.
What happened
Run 40426742043 (candidate af408eac, tag v2.5.46) passed every build, gate and the macOS wheel smoke tests, then Publish PyPI failed:
Uploading fbuild-2.5.46-cp310-abi3-macosx_10_12_x86_64.whl
Response from https://upload.pypi.org/legacy/: 200 OK
Uploading fbuild-2.5.46-cp310-abi3-macosx_11_0_arm64.whl
Response: 400 Bad Request
400 Project size too large. Limit for project 'fbuild' total size is 10 GB.
https://docs.pypi.org/project-management/storage-limits/#requesting-a-project-size-limit-increase
ERROR HTTPError: 400 Bad Request
Project total from the PyPI JSON API: 10.706 GB in 180 versions / 545 files. A release is 5 wheels ≈ 210 MB, so the project ran out of quota mid-upload.
Impact
Only macosx_10_12_x86_64 has 2.5.46:
platform
pip/uv install fbuild
fbuild==2.5.46
Intel macOS
2.5.46
2.5.46
Linux x86_64 / aarch64
resolves to 2.5.45
fails: "no wheels with a matching platform tag"
Windows x86_64
resolves to 2.5.45
fails
Apple Silicon
resolves to 2.5.45
fails
So 2.5.46 (the local lib_deps fix, #1751) is not delivered to anyone but Intel macOS, and PyPI labels 2.5.46 as latest.
Remediation (needs a maintainer; not reachable from CI)
PyPI has no file-delete API and this project publishes via trusted publishing (no token), so neither half can be automated:
Re-dispatch Autonomous Release with candidate_sha=af408eac (dispatch from tag v2.5.46) and publish=true. prepare then sees PyPI files for 2.5.46: 1 < 5, sets should_publish_pypi=true / should_publish_github=false, and gh-action-pypi-publish with skip-existing: true uploads only the 4 missing wheels.
Follow-ups worth considering
prepare already downloads the PyPI JSON; it could sum the project size + built wheels and refuse to publish (before uploading anything) with the storage-limit message, instead of stranding a version on the first rejected file. Today build_wheel guards missing lanes but nothing guards quota.
Each wheel is ~42 MB because it carries fbuild, fbuild-daemon and the PyO3 extension; 180 patch releases ≈ 10.7 GB. If the quota cannot be raised, the growth rate needs addressing at the packaging level.
Steward status check against live PyPI while fixing the quota guard:
The stranding half of this issue is resolved.https://pypi.org/pypi/fbuild/json now reports:
latest version 2.5.47
2.5.46 has 5 files (204 MB) — the missing wheels were uploaded
project is 92 versions / 9.870 GB (was 180 versions / 10.706 GB), so old releases were pruned
The underlying risk is not resolved: ~130 MB of headroom remains, and one release is ~204 MB. The
next release will hit the same mid-upload 400 and strand again, because nothing in the pipeline looks
at project size before the first file is uploaded.
Delivering the guard suggested in your "Follow-ups" section as #1787:
prepare estimates the missing wheels' weight (from this version's stored files, else the largest
wheel of an older release) and refuses the dispatch before anything uploads.
build-pypi repeats it with the real wheel sizes against live PyPI JSON, right before publish-pypi.
python -m ci.publish --pypi-json ... [--version V --expected-wheels N | --wheel ...] is the
shared CLI; it prints the verdict and exits non-zero.
Verified against the live JSON in this run: 2.5.46 is allowed (exit=0), a 204 MB release is refused
with would exceed the limit by 84 MB (exit=1). Docs in docs/RELEASING.md cover both guards and
the maintainer recovery path.
Still requires you (not reachable from CI): either request a project size increase or prune older
PyPI releases — preferably before the next version bump, since one release no longer fits.
Activity
zackees commentedon Oct 29, 2026
Steward status check against live PyPI while fixing the quota guard:
The stranding half of this issue is resolved.
https://pypi.org/pypi/fbuild/jsonnow reports:The underlying risk is not resolved: ~130 MB of headroom remains, and one release is ~204 MB. The
next release will hit the same mid-upload 400 and strand again, because nothing in the pipeline looks
at project size before the first file is uploaded.
Delivering the guard suggested in your "Follow-ups" section as #1787:
prepareestimates the missing wheels' weight (from this version's stored files, else the largestwheel of an older release) and refuses the dispatch before anything uploads.
build-pypirepeats it with the real wheel sizes against live PyPI JSON, right beforepublish-pypi.python -m ci.publish --pypi-json ... [--version V --expected-wheels N | --wheel ...]is theshared CLI; it prints the verdict and exits non-zero.
Verified against the live JSON in this run: 2.5.46 is allowed (
exit=0), a 204 MB release is refusedwith
would exceed the limit by 84 MB(exit=1). Docs indocs/RELEASING.mdcover both guards andthe maintainer recovery path.
Still requires you (not reachable from CI): either request a project size increase or prune older
PyPI releases — preferably before the next version bump, since one release no longer fits.