Python and JavaScript distribution: pip wheel and npm package

[GeneralPawz]

Add pip, add npm

[GeneralPawz]

Scoping this out so it is actionable, then parking it.

What exists today

axiolid-capi is the only non-Rust surface. It builds as rlib/staticlib/cdylib and exports a versioned C ABI (axiolid_v0_4_*), consumed through native/CMakeLists.txt and the installed CMake package.

There are no Python or JavaScript bindings in the tree: no pyo3, maturin, wasm-bindgen, or napi anywhere in a Cargo.toml. So this is not a packaging task over an existing binding -- the binding layer has to be built first, and that is the bulk of the work.

The real decision

A distribution channel is downstream of a binding strategy, and the two ecosystems do not want the same thing.

Python. Two routes:

• pyo3 + maturin -- idiomatic Python objects, pip install axiolid ships an abi3 wheel per platform. Real binding code to write and maintain, but the result is what a Python user expects.
• ctypes/cffi over the existing C ABI -- almost no new Rust, but every caller hand-marshals handles and status codes. Cheap to ship, unpleasant to use.

JavaScript. Split by target:

• Browser: wasm-bindgen + wasm32 target. Note the kernel would need to build under wasm at all -- rayon threading in the boolean path is the obvious blocker and needs checking before this is promised.
• Node: napi-rs against the native library, no wasm constraint, but a separate artifact matrix.

These are three different products (pip wheel, npm wasm package, npm native addon), not one task.

What would have to be decided first

1. Which API surface gets bound. The full facade, or a deliberately narrow subset? A binding is a public API with its own compatibility burden -- every function exposed is one that cannot change freely afterwards.
2. Who owns the release. These add per-platform build matrices (manylinux, macOS arm64/x86_64, Windows) to a release process that currently publishes 52 crates to one registry. That is a real increase in release surface.
3. Versioning. Do the wheel and npm package track the kernel version exactly, or move independently? Tracking exactly means a Python release for every Rust patch.
4. Whether wasm is even reachable. Needs a spike: does the kernel compile to wasm32 with rayon disabled, and is it useful without threads?

Done when

Not defined yet -- that is the point of parking it. A useful first step is a spike, not an implementation: try pyo3 over a deliberately tiny surface (create a context, load a mesh, one boolean, read the result back) and report what the binding code actually costs. That answers decisions 1 and 2 with evidence instead of speculation.

Unblock condition

Pick this up when there is a named consumer who wants it -- a specific Python or JS project that would use the kernel. Bindings built without one tend to bind the wrong surface, and the maintenance lands regardless of whether anyone installs the package.

Until then: scoped, parked, not scheduled.