Publish PyEmscripten wheel to PyPI#278
Conversation
|
Warning Review limit reached
Next review available in: 37 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe WASM wheel build now targets PyEmscripten through cibuildwheel and Pyodide 314, packages ChangesPyEmscripten release flow
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant ReleaseWASM
participant CIBuildwheel
participant Pyodide314
participant PyPI
ReleaseWASM->>CIBuildwheel: Build the PyEmscripten wheel
CIBuildwheel->>ReleaseWASM: Produce wheelhouse/*.whl
ReleaseWASM->>Pyodide314: Install wheel and run load probe
Pyodide314->>ReleaseWASM: Return runtime verification
ReleaseWASM->>PyPI: Publish dist-pyemscripten artifact
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Merging this PR will not alter performance
Comparing 
Footnotes
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
tests/test_pyodide_load_smoke.py (1)
22-45: 🗄️ Data Integrity & Integration | 🔵 Trivial | ⚡ Quick winCover package-name installation separately.
This test only verifies direct URL forwarding, while the release documentation now promises
micropip.install("xy"). Add a Pyodide/PyPI smoke case for package-name resolution, or explicitly identify an existing test that validates thepyemscripten_2026_0_wasm32wheel is selected.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@tests/test_pyodide_load_smoke.py` around lines 22 - 45, Add a separate smoke test alongside test_remote_wheel_url_is_installed_directly that passes the package name "xy" to pyodide_load_smoke.main and verifies the generated driver calls micropip.install with that package name, while preserving the existing direct-URL forwarding assertion. If an existing test already exercises PyPI resolution, update or reference it to assert selection of the pyemscripten_2026_0_wasm32 wheel..github/workflows/release.yml (1)
134-188: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winAdd an explicit
permissions:block to thewasmjob.This job runs several third-party actions plus
cargo buildand an ad-hocnpm iunder the default (broader)GITHUB_TOKENpermissions. Static analysis (zizmor) flags this as excessive-permissions since nopermissions:block scopes it down.🔒 Proposed fix: scope down default permissions
wasm: name: Wheel PyEmscripten (runtime verified) runs-on: ubuntu-latest + permissions: + contents: read steps:🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/release.yml around lines 134 - 188, Add an explicit least-privilege permissions block to the wasm job, granting only the permissions required by its checkout and artifact upload steps. Keep the existing build, verification, runtime probe, and third-party action configuration unchanged.Source: Linters/SAST tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@README.md`:
- Around line 60-65: Update the Pyodide 314 installation example in README.md to
load the micropip package with pyodide.loadPackage before the Python import,
preserving the existing micropip.install flow and showing the required
JavaScript/Python sequence.
---
Nitpick comments:
In @.github/workflows/release.yml:
- Around line 134-188: Add an explicit least-privilege permissions block to the
wasm job, granting only the permissions required by its checkout and artifact
upload steps. Keep the existing build, verification, runtime probe, and
third-party action configuration unchanged.
In `@tests/test_pyodide_load_smoke.py`:
- Around line 22-45: Add a separate smoke test alongside
test_remote_wheel_url_is_installed_directly that passes the package name "xy" to
pyodide_load_smoke.main and verifies the generated driver calls micropip.install
with that package name, while preserving the existing direct-URL forwarding
assertion. If an existing test already exercises PyPI resolution, update or
reference it to assert selection of the pyemscripten_2026_0_wasm32 wheel.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: f47cb542-bdd3-4191-9d07-dcf1cfbea429
📒 Files selected for processing (9)
.github/workflows/release.ymlCHANGELOG.mdREADME.mdhatch_build.pyscripts/verify_ci_workflow.pyspec/process/production-readiness.mdtests/test_hatch_build.pytests/test_pyodide_load_smoke.pytests/test_verify_ci_workflow.py
…ipten-wheel # Conflicts: # scripts/verify_ci_workflow.py
1 participant
What changed
cibuildwheel4.1.0 forcp314-pyodide_wasm32/ Pyodide 314.0.0.pyemscripten_2026_0_wasm32platform and publish the runtime-verified wheel through the existing trusted-PyPI artifact batch.await micropip.install("xy").libxy_core.sobased on the target rather than the build host, so cibuildwheel works from both Linux and macOS.Why
PEP 783 and Pyodide 314 make
pyemscripten_*a standard PyPI wheel platform. The previouspyodide_2025_0_wasm32wheel could not be uploaded to PyPI and had to be installed from a GitHub Release URL.A production-equivalent macOS build also exposed that the build hook derived the packaged library suffix from the host. That produced
libxy_core.dylib, while Pyodide's dynamic loader expectslibxy_core.so; the target-aware destination fixes that masked cross-host bug.Impact
The next tagged release will publish a Pyodide 314-compatible WASM wheel alongside the native wheels and sdist. Browser users get normal package-name installation through
micropip, while the existing ABI/version/content/runtime gates remain release-blocking.Validation
make check— 2,189 passed, 68 skipped; all 8 gates passed (the existingtyfindings remain advisory)xy-0.0.2-py3-none-pyemscripten_2026_0_wasm32.whlscripts/verify_wheel.py --expect-nativepassed on that artifactbackend=native, ABI 41,min_max=(1,3)Summary by CodeRabbit
xyin the browser using micropip.libxy_core.sofor Pyodide’s loader expectations.