Packaging: conda vs. wheel

In pixi mode a tin is a source dependency: pixi fetches the tin's repo at its registry-pinned commit and builds it into a conda package in your environment. The conda machinery underneath does real work for us:

What conda does for tins

• Builds from source, automatically. The pixi-build-mojo backend compiles the tin's Mojo package (.mojopkg) on install; C and Rust FFI shims build as sibling packages (cmake or rattler-build recipes) the tin run-depends on.
• Import resolution for free. Packages land in $CONDA_PREFIX/lib/mojo, where the Mojo compiler finds them — no -I flags in your build commands.
• A native dependency graph. Shims link real libraries (libz, OpenSSL, …) from conda-forge; conda resolves and installs them into the same environment and relocates rpaths so everything loads at runtime.
• Toolchain coherence. Compiled Mojo packages are tied to a compiler version; the solver enforces one mojo-compiler across every tin in the environment.
• Transitive builds. A tin that imports another tin (docx → zlib-mojo) declares it as a git-pinned host dependency; the dependency is built into the build environment first.

The same machinery distributes the shelf CLI itself: a conda package on the static channel at /channel, installed with pixi global install.

A pypi/wheel backend?

Wheels are a plausible additional distribution for pure-Mojo, Python-facing tins: PyPI hosting is universal, uv is fast, plain venvs could consume tins, and pixi speaks PyPI natively. What's missing today: a PEP 517 build backend for Mojo (the wheel-world equivalent of pixi-build-mojo), a convention for finding .mojopkgs in site-packages, and per-wheel vendoring of native shim libraries — wheels have no shared native dependency graph, so each shim must bundle its dylibs. Conda stays the primary substrate; a wheel experiment would start with a Python-interop tin like pontoneer.