feat: Publish conda/pixi packages so native deps like libheif resolve

Requested by u/DarkMatterDetective on r/dataengineering, with a concrete failure behind it.

The report

Tried uvx --from xberg-cli on WSL2 Ubuntu and hit an out-of-date libheif (v1.0.8) on the system. They manage their stack with conda and asked whether we would publish a conda/pixi package.

Why the wheel can't fix this

libheif is a system shared library the wheel links against, not a Python dependency. uv, pip and pipx all resolve Python packages only — none of them can upgrade the distro's libheif, and on WSL2 Ubuntu the apt pin is whatever the base image shipped. The user is stuck unless they build libheif themselves or leave the Python packaging world entirely.

This is precisely the gap conda exists to fill: it ships the native libraries as first-class packages alongside the Python ones, so libheif is resolved and installed rather than assumed.

Current workarounds (what I told them)

Both bypass the system library entirely:

docker run ghcr.io/xberg-io/xberg
brew install xberg-io/tap/xberg

These work, but "use Docker" is a poor answer for someone whose whole toolchain is conda-managed.

Ask

Publish xberg (and xberg-cli) to conda-forge, with the native dependencies — libheif, and whatever else the extraction pipeline links against — declared properly so conda resolves them.

Worth checking as part of scoping:

• Full list of system libraries the wheels link against per platform, and which of those already have conda-forge feedstocks.
• Whether one feedstock covers the CLI and the Python package or they need separate recipes.
• pixi is a conda-ecosystem client, so a conda-forge package satisfies that request too — no separate work needed.
• conda-forge requires a staged-recipes PR and ongoing feedstock maintenance. That maintenance cost is the real decision here, not the initial recipe.

Related

Same shape as the npm/PyPI wrapper work in Goldziher/scythe#80: distribution reach limited by packaging rather than by the software.