Mention wasm-tools-package, a PyPI distribution of the wasm-tools binary, in the README #2789

Hi! I maintain wasm-tools-package, an unofficial PyPI package that ships the prebuilt wasm-tools executable. I'd like to offer it to the Bytecode Alliance; the options are at the end. It needs no change in how wasm-tools itself is built or released.

What it is

wasm-tools-package (source) puts the prebuilt wasm-tools executable into a Python wheel, so that

pip install wasm-tools-package
wasm-tools parse add.wat -o add.wasm

works on any common platform without Rust, cargo or network access at run time. It is unofficial and says so; it is built from the unmodified wasm-tools source at a release tag. It contains nothing but the wasm-tools executable and a thin Python wrapper (run(), get_executable()), and it changes none of wasm-tools' behaviour.

Why it exists

Python projects increasingly need WebAssembly tooling at build time: for example a project that turns a .wat into a .wasm, or wraps a core module into a component, while building its own wheel. In Python, build-time tools are declared as dependencies and installed by pip/uv from an index:

[build-system]
requires = ["wasm-tools-package>=1.262,<1.263"]

That gives three things which cargo install wasm-tools, a downloaded release archive, or bytecodealliance/actions/wasm-tools/setup cannot give a Python build:

1. A version pin in the lock file. uv.lock / pip --require-hashes record the exact version and checksum of every build tool, so the build is reproducible and auditable.
2. No toolchain and no network at build time. cargo install needs Rust and crates.io and compiles for minutes; a wheel is just unpacked.
3. It works wherever pip works: one py3-none-<platform> wheel per platform (manylinux/musllinux x86_64, aarch64, i686, armv7l; Windows x64, ARM64, x86; macOS arm64, x86_64, universal2), built with cibuildwheel. This is the same way cmake, ninja, ruff, uv and clang-format are distributed on PyPI. (A wheel is a zip with a platform label; it may contain a compiled program.)

How it is made and kept in sync

• wasm-tools is a git submodule pinned to a release tag. The package version is <wasm-tools version>.<build>: 1.262.0.0 is wasm-tools 1.262.0, build 0. CI refuses a tag that does not start with the release the submodule is on, so the version cannot drift from what is inside.
• The sdist and all wheels are built in GitHub Actions and published with PyPI trusted publishing (no stored token). Each wheel is tested on its own platform, including a check that the executable depends on nothing but the system's own libraries.
• Following a new release is automatic. A workflow runs once a day (wasm-tools releases about once a week) and looks for the highest released version. If it is newer than the pin, it opens a PR that moves the submodule to that tag, and the PR runs the full build and tests on every platform. Only if everything is green does the PR get merged, followed by the package tag v<release>.0, which builds and publishes to PyPI. A red PR is left open for the maintainer, and a step that fails (the merge, the tag push) is retried by the next run. Patch releases of older branches (e.g. v1.254.2 published after v1.258.0) are ignored, so the pin never goes backwards.

About the name

The name wasm-tools on PyPI is already taken by an unrelated project (a pure-Python wasm parser, appthreat/wasm-tools), which is why this one is called wasm-tools-package. To avoid confusion: they share nothing with wasm-tools of this repository.

What I am proposing

I'm a solo maintainer, and that is the only reason I'm asking: if I suddenly couldn't continue for some reason, nobody would carry the package on, and Python projects that pin it would be stuck. I'll keep maintaining it either way and follow every release, so keeping it up to date is not a concern. Two ways to make it official, whichever you prefer:

1. A separate repository under the bytecodealliance org, transferred as is (it is a small repo: a git submodule pointing at wasm-tools, a build script, a publish workflow). I'd stay as maintainer, and the PyPI project can be owned by the org.
2. A PR into this repository, e.g. a python/ directory with the packaging and a workflow that publishes on a release tag, if you'd rather have it next to the source and released together with it.

The sync is already automatic (see above), so nothing is needed on your side. No release process of wasm-tools would change, and nobody has to remember to publish: a new wasm-tools version and its pip install appear within a day, only after a fully green build. A transfer would add continuity (the bus factor above) and an official, trustworthy source for the package, with PyPI trusted publishing configured for the org's repository so that no tokens are shared. (The workflow needs one repository secret with write access to the repo itself; it is the only credential, and it never leaves the repository.)

I understand that every extra repo and package has a cost, so I tried to keep it low: no dependencies, no code of its own beyond a ~100 line wrapper, and a new wasm-tools release is followed by the workflow without anyone touching it.

If neither fits, that's completely fine: I'll continue maintaining it under my account (natify-sh/wasm-tools-package). In that case I'd be glad to send a PR adding one line to the "Installation" part of the README, e.g.:

Prebuilt binaries are also available from PyPI (unofficial): pip install wasm-tools-package.

Happy to answer any question about the packaging. Thanks for wasm-tools!