PyPI 開始收 WASM wheel，Pyodide 包裝順多了
PyPI 已支援 Pyodide 可用的 WASM wheel，讓套件作者能直接上傳瀏覽器版 Python 二進位檔，減少 Pyodide 團隊手動維護 300 多個套件的負擔。
PyPI 現在能收 Pyodide 可用的 WASM wheel，讓瀏覽器版 Python 的套件發佈流程簡單很多。
這件事看起來小，實際上很有感。Pyodide 是把 Python 編譯到 WebAssembly 的專案，主打在瀏覽器裡直接跑 Python。以前它最大的痛點不是執行速度，而是套件包裝。
2026 年 6 月 13 日，Simon Willison 提到，現在能把 WebAssembly 版 Python 套件直接發到 PyPI。這代表 Pyodide 不用再走一條很怪的分發路線。對開發者來說，這種改動比宣傳詞實在多了。
更直白地說，這是把「瀏覽器版 Python」拉回正常軟體發佈流程。以前像特例，現在比較像一般套件管理。
| 指標 | 數值 | 意義 |
|---|---|---|
| Pyodide 團隊原本維護的套件數 | 300+ | 手動包裝壓力很大 |
| 已使用新 WASM 標籤的 PyPI 套件 | 28 | 代表新流程已經有人在用 |
| luau-wasm wheel 大小 | 276 KB | 顯示瀏覽器可用 wheel 可以很小 |
| PyPI PR 合併日期 | 2026-04-21 | 這不是構想，已經落地 |
PyPI 到底改了什麼
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
這次核心更新，是 PyPI 新增了一種 wheel 平台標籤：pyemscripten_202*_wasm32。講白了，就是讓套件作者可以把 WebAssembly 版本的 wheel 當成正常 wheel 上傳。
這個變化不只是格式名稱不同。它代表 PyPI 已經把這類工件納入正式分發流程。套件作者不用再找旁路，也不用自己另外架一套下載點。
對 Pyodide 來說，這超重要。因為它不是玩具專案，而是一個完整 Python 執行環境。它把 Python、標準函式庫，還有一部分第三方套件搬進瀏覽器。當套件發佈變簡單，能用的東西就會變多。
- 舊做法：Pyodide 團隊自己建、自己 host、自己審。
- 新做法：套件作者直接上傳 WASM wheel 到 PyPI。
- 好處：少很多人工流程，也少很多維護成本。
- 結果：瀏覽器版 Python 能接到更多第三方套件。
Simon Willison 怎麼證明它能用
Willison 不是只講概念。他直接做了一個實驗，叫做 luau-wasm，然後把它發佈到 PyPI。這個專案包的是 Luau，也就是 Roblox 用的那個輕量語言，底層是 C++。
他還用了 Claude Code 跟 GPT-5.5 幫忙處理打包和 GitHub Actions。這段很有現實感。因為很多套件卡住，根本不是演算法問題，而是建置流程很煩。
最後產出的 wheel 只有 276 KB，檔名是 luau_wasm-0.1a0-cp314-cp314-pyemscripten_2026_0_wasm32.whl。這數字很關鍵。它代表 browser-ready 的 binary 不一定很肥，很多情況下甚至比你想像中小很多。
「往後，套件維護者可以像發佈 Linux、macOS 或 Windows 的 native wheel 一樣，直接發佈 Pyodide wheel 到 PyPI。」
這句話講得很直接。意思就是，瀏覽器版 Python 不用再被當成特別分支處理。套件作者只要多做一個 target，就能進到同一套發佈邏輯。
他還用了 cibuildwheel 和 GitHub Actions 來自動化建置。Demo 則放在 simonw.github.io/luau-wasm，直接在瀏覽器載入 Pyodide、安裝套件、執行程式。
28 個套件透露了什麼
Willison 還去查了 PyPI 的公開 BigQuery 資料集，找到 28 個已經用新 WASM 標籤發佈的套件。這不是一個很大的數字，但已經夠看出方向。
名單裡有 pydantic_core、onnx、typst，還有 yaml-rs、toml-rs 這類 Rust-backed 套件。這些專案有個共通點，就是本來就帶有編譯產物。
所以這波最先吃到紅利的，不是純 Python 小工具，而是本來就有 native code 的套件。這很合理。因為這些專案原本就得處理平台差異，現在只是多了一個 WebAssembly 目標。
- luau-wasm：最新的示範案例。
- pydantic_core：很多 Python 專案都會碰到。
- onnx：機器學習工具鏈常見元件。
- typst：編譯型工具很適合這種分發方式。
如果你在做瀏覽器端 Python App，這個數字的意義很直接。你開始可以想像，依賴套件不必再靠一堆客製化下載點，而是回到 PyPI 這個大家熟悉的入口。
跟舊流程比，差在哪裡
以前 Pyodide 團隊要自己扛很多事。他們得建置、託管、審查超過 300 個套件。這種工作很像幫整個生態系當代工廠，久了誰都會累。
新流程比較像正常軟體發佈。套件作者自己產出 WASM wheel，再交給 PyPI。Pyodide 只要在執行期安裝就好，不用每個套件都額外跑一輪人工流程。
這裡的差異不是「比較方便」而已。它直接影響誰願意維護、誰願意發版、誰願意把套件做成可在瀏覽器跑的版本。流程越怪，參與的人就越少。
- 舊流程：Pyodide 團隊是瓶頸。
- 新流程：套件作者自己負責發佈。
- 舊流程：每個套件都像特殊案件。
- 新流程：WASM wheel 變成一般發佈選項。
如果你有做過 CI/CD，就知道這差很多。當流程能自動化，團隊才有空去處理真正難的問題。像是相容性、效能、記憶體占用，這些才是該花時間的地方。
這跟整個 Python 生態有什麼關係
PyPI 是 Python 世界的中心入口。它不是單純的下載站，而是很多工具鏈、建置流程、依賴管理的共同地基。當它開始接受 WASM wheel，等於把瀏覽器端 Python 也拉進這個中心化流程。
這對開發者很實際。你不用再為 Pyodide 準備一套完全不同的包裝邏輯。對團隊來說，這種一致性很重要，因為它會直接影響維運成本。
從產業角度看，這也會讓更多工具願意嘗試 browser runtime。像資料處理、教學、互動筆記本、前端原型，這些場景本來就適合在瀏覽器跑。現在少了包裝障礙，試錯成本也低一些。
我覺得最值得觀察的，不是這次支援本身，而是後面會有多少套件跟進。28 個還不多，但如果接下來變成 100、200，整個使用體驗就會差很多。
接下來幾個月，最值得看的指標很簡單：有多少熱門套件開始出 WASM wheel、有多少專案把 Pyodide 當正式 target。你如果有在維護 Python 套件，現在就該想一下自己的 build pipeline 能不能多長出一個 WebAssembly 目標。
講白了，這次不是新聞稿等級的熱鬧，而是基礎設施真的補了一塊。補得不花俏，但很有用。