Skip to content

release(2.5.46): PyPI publish stranded at 1/5 wheels — project hit the 10 GB storage limit #1756

Open

Description

@zackees

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:

  1. Either request a project size increase — https://docs.pypi.org/project-management/storage-limits/#requesting-a-project-size-limit-increase — or delete old releases in the PyPI web UI to free ~1 GB.
  2. 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.

Activity

  1. zackees commented on Oct 29, 2026

    @zackees
    MemberAuthor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions