ci(publish-python): drop PyPI wheel push, GH Release becomes canonical#44
Merged
Conversation
The Python SDK matrix (4 CPython × 3 platforms = 12 wheels per release, ~17 MB each) burned through PyPI's 10 GB per-project quota and tripped v3.2.0 with `400 Project size too large` mid-upload. PyPI offers no API to delete files; even after manually clearing the 1.x series, every future release would just refill the quota. GitHub Releases has no per-project size cap and the workflow already uploads the full wheel set + a `python-native-manifest.json` index there. Stop pushing to PyPI and call GH Releases the canonical wheel host. Changes - publish-python.yml: remove the `Publish wheels to PyPI` step entirely. The `if: startsWith(github.ref, 'refs/tags/')` guards on the GH-Release steps stay (they were added for debug dispatch and remain valid for branch dispatch). - release.sh: update the post-release summary text to reflect the new Python distribution path. - README + sdk/python/README: replace `pip install a3s-code` with a concrete GH-Release URL example, and explain why. Note that ≤3.1.0 versions remain installable from PyPI. - CHANGELOG: add a [3.2.0] Packaging note documenting the change. PYPI_NATIVE_TOKEN repo secret is now unused — leave for the user to revoke / delete from repo settings as a separate step.
6 tasks
ZhiXiao-Lin
pushed a commit
that referenced
this pull request
May 24, 2026
… from GH Releases After v3.2.0 stopped publishing native wheels to PyPI (PR #44, GH Releases is the canonical host), `pip install a3s-code` was broken on every platform except cp310 macOS arm64 (the one wheel that snuck into PyPI before the 10 GB project cap kicked in). This commit restores `pip install a3s-code` by adding a tiny pure-Python bootstrap package — also named `a3s-code` — that on first `import a3s_code` downloads the matching native wheel for the current interpreter and platform, verifies its sha256 against the release manifest, extracts the compiled `_native` extension into a per-user cache, and registers it as `sys.modules["a3s_code._native"]`. Subsequent imports use the cache; cold start is one download per (version, platform, interpreter) triple. New package - sdk/python-bootstrap/ — setuptools-built pure-Python wheel (a3s_code-X.Y.Z-py3-none-any.whl) and matching sdist. - src/a3s_code/__init__.py — calls ensure_native_loaded() then `from ._native import *`. - src/a3s_code/_bootstrap.py — wheel-name resolver, downloader, sha256 verifier, extension loader. Knobs: A3S_CODE_CACHE_DIR, A3S_CODE_RELEASES_BASE_URL, A3S_CODE_SKIP_HASH_CHECK. - tests/test_bootstrap.py — 15 unit tests (filename resolution, cache dir, sha256 mismatch, idempotency, manifest fallback) plus one live download test gated on A3S_CODE_BOOTSTRAP_LIVE=1. - README documenting install model and overrides. Workflow - publish-python-bootstrap.yml — runs bootstrap unit tests, builds wheel + sdist, twine check, twine upload on tag push. - release.yml — adds the bootstrap publish job; runs after publish-python (which produces the GH Release the bootstrap points at) and gates github-release on both. Release plumbing - scripts/check_release_versions.sh now validates the bootstrap pyproject.toml and the runtime __version__ in _bootstrap.py — they must equal the core version so the bootstrap finds the matching GH Release tag. - release.sh bumps both in lockstep with the other version files. - README + sdk/python README rewritten to advertise pip install a3s-code again and explain the cache. Bumps core / Node SDK / Python SDK from 3.2.0 to 3.2.1 since the bootstrap is a user-facing addition. CHANGELOG [3.2.1] entry documents the new package + rationale. End-to-end verified locally: built the wheel, installed into a fresh venv, ran `import a3s_code` with __version__ patched to 3.2.0 so the bootstrap points at the real GH Release; Agent.create succeeded.
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
2 participants
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.
Why
The Python SDK matrix (4 CPython × 3 platforms = 12 wheels per release, ~17 MB each) burned through PyPI's default 10 GB per-project quota and tripped v3.2.0 with `400 Project size too large` mid-upload (verbose error from #43). Even after manually clearing 1.x to drop from 9.99 GB → 1.58 GB, every future release would just refill the budget.
GitHub Releases has no per-project size cap and the workflow already uploads the full wheel set + `python-native-manifest.json` index there. Switch to GH Releases as the canonical wheel host.
Changes
Follow-ups for you