Simon Willison 做了一个很小的验证，但信息量不小：他把 luau-wasm 发到 PyPI，产物是一个 276KB 的 wheel，在 Pyodide 里用 micropip.install("luau-wasm") 就能安装运行。

这件事的重点不在 Luau，也不在这个包有多大。重点是：面向 PyEmscripten/WASM 的 Python wheel，现在可以走 PyPI 这条主路了。

WASM wheel 终于能进 PyPI

Pyodide 314.0 的发布公告里，有一条对包维护者很实际的变化：为 Pyodide，或任何兼容 PEP 783 所定义 PyEmscripten 平台的 Python 运行时构建的包，可以直接发布到 PyPI。

PEP 783 定义的平台标签形如：pyemscripten_202*_wasm32。

PyPI 支持这类标签的 PR 已在 4 月 21 日合并。也就是说，包维护者可以像发布 Linux、macOS、Windows wheel 一样，发布给 Pyodide 使用的 WASM wheel。

维度过去现在
分发位置Pyodide 项目自行构建、托管包维护者可直接发到 PyPI
安装方式依赖 Pyodide 维护的包集合Pyodide 运行时可用 micropip 安装
平台标签缺少标准 PyPI 分发入口使用 pyemscripten_202*_wasm32
维护压力300 多个包由 Pyodide 维护者承担责任开始回到上游包作者
新包进入需要人工审核更接近 Python 常规发布流程

Simon 的 luau-wasm 是一个好例子。Luau 是 Roblox 开发的、基于 Lua 的小型嵌入式语言，源码是 C++。它可以编译到 WebAssembly，再通过 Pyodide 在浏览器里跑。

这类包过去不是完全不能做。麻烦在分发。C、C++、Rust 扩展能不能编到 WASM是一回事，编完后怎么让别人稳定安装，是另一回事。

现在这后一段路短了。

真正拆掉的是 300 多个包的人工瓶颈

Pyodide 过去最累的地方，不是运行时本身。它已经能把 Python 带进浏览器，适合教学、演示、数据处理、轻量工具和部分端侧计算。

卡住的是包。

发布公告里说得很直白：此前 Pyodide 维护者要自己维护、构建、托管 300 多个包。每加入一个新包，都需要人工审核。

这就是开源基础设施的老问题：用户只问一句“能不能装”，维护者背后要处理构建矩阵、ABI、依赖、兼容性和托管成本。

现在 PyPI 接住 PyEmscripten/WASM wheel，变化不在口号上，而在分工上：

对象直接影响
Python 包维护者如果库适合浏览器运行，可以开始把 WASM wheel 纳入发布流程，而不是等 Pyodide 维护者代打包
WebAssembly / 浏览器端计算开发者选型时可以优先看依赖是否已有 pyemscripten_202*_wasm32 wheel，减少自建构建链
Pyodide 维护者从“替社区托管包”退回到维护运行时和基础兼容层，压力更合理

按 Simon 基于 PyPI BigQuery 公共数据的查询，如果查询正确，目前大约有 28 个 PyPI 包发布了新的 pyemscripten_202*_wasm32 平台标签 wheel。

这个数不是官方统计，也不该被吹大。28 个只能说明门开了，生态还在刚起步。

但方向很清楚：以后判断一个 Python 包能不能好好进入浏览器，不只看它能不能编译到 WASM，还要看维护者愿不愿意把 WASM wheel 当成正式发布目标。

浏览器里的 Python，缺的是可持续分发

我更在意的是这点：浏览器里的 Python 过去并不缺“能跑”的故事，缺的是可持续的分发秩序。

运行时是入场券。包分发才决定生态能不能长大。

这次改动也不能夸过头。不是所有 Python 包都能无缝进浏览器。尤其是带 C、C++、Rust 扩展的包，仍然要满足几个现实条件：

  • 扩展代码能编译到 WASM；
  • 依赖能适应 Pyodide / PyEmscripten 环境；
  • 浏览器运行时限制可接受；
  • 文件系统、线程、网络、系统调用等行为不能强依赖原生服务器环境。

对包维护者来说，接下来最该做的不是盲目加标签，而是先分清自己的库属于哪类。

纯 Python、轻依赖、计算逻辑清晰的库，最适合先试。依赖本地系统库、重 I/O、强线程模型、复杂原生扩展的库，成本会高很多。

安全边界也要说清。浏览器沙箱降低了部署门槛，不等于供应链风险消失。PyPI 上能装，意味着安装路径更顺，也意味着依赖投毒、恶意包、版本污染这些老问题会一起进入浏览器端计算。

“天下熙熙，皆为利来。”技术生态也一样。开发者会流向阻力更小、收益更清楚的地方。

Pyodide 这次做对的，是不再把自己放在生态门口当人工分拣员。它把路接回 Python 的主干道。

接下来最该观察两个变量。

第一，pydantic_core、onnx 这类更有实际使用面的包，WASM wheel 能否稳定维护，而不是只发一次尝鲜。

第二，构建工具链能不能继续降低门槛。Simon 的示例用了 GitHub Actions 和新版 cibuildwheel。如果这条链路足够顺，包维护者才会把它放进日常发布，而不是当成周末实验。

门开了。但车能不能多起来，要看上游愿不愿意长期上路。