Using a separately-packaged libwasmtime

[bollwyvl]

Thanks for this tool!

I'd like to package wasmtime and (at least initially) wasmtime-py on conda-forge, a cross-platform, distro-style package ecosystem.

Looking through this package's PEP-517 build system, I see it's:

• downloading and renaming a .(so|dylib|dll) at build time
• stashing it in site-packages
• discovering via relative paths at runtime

However, I also see more upstream tags of wasmtime than PyPI releases of wasmtime-py, e.g. at present 39.0.0.1 vs 39.0.0.0, and the more troublesome historic CVE fix versions.

For a downstream like conda-forge, would it be unreasonable/unadvisable to:

• build the libwasmtime C API from source
• patch wasmtime-py to...
  • at build time, skip downloading
  • at runtime, look in the Normal Places (e.g. $PREFIX/lib) for libwasmtime.*
• pin wasmtimepy to the major version of libwasmtime

Thanks again.

[alexcrichton]

If you're willing I'd personally prefer to have build-from-source logic live in this repository. There's fiddly knobs to turn and as a maintainer of Wasmtime and its C API I would be willing to help out navigate all that. I don't know exactly what it would look like for the logic to live here, but if it could that'd be nice (and it could be tested in CI).

Version-wise it's basically an artifact of how this repository is a separate one from Wasmtime. Neither will follow the others' version exactly due to this, although aligning major versions is attempted. I realize though this creates a confusing situation, but I'm not sure how to overcome that short of merging the repos together.

[bollwyvl]

Welp, avoidance of supporting users with cross-platform, polyglot build systems to "just" pip install is part of why I invest time in packaging for conda-forge 😊 Unfortunately, however, I'm rather out of my depth on actually implementing of the following suggestions.

I think given upstream already has a whole cmake thing going on, it might indeed make sense to have the python chunk live over there, even if by (another) submodule that ends up in the "fat" release tarball (thanks for that!).

Or, go (back?) to crates/wasmtime-py and use maturin... the abi3 feature would shave off a whole matrix factor, keeping things away from the cpython 3.9-3.14t tarpit.

[bollwyvl]

For reference, here's my strawman (only tested on linux-64) PR that might eventually add this to conda-forge:

conda-forge/staged-recipes#31693

Depending on how it is reviewed by wiser folk, it would probably end up being multiple repos due to the difference in upstream release cadence. We also only (cross) build for a small subset of the {os x arch} matrix wasmtime supports; these would be incrementally added as follow-on PRs.

[alexcrichton]

As a maintainer of this repo I would say that now's not the right time to merge this repo with the main Wasmtime repo. There's basically not enough Python expertise in Wasmtime to maintain this as well there.

In any case if there's something that needs to change here in this repo to make the packaging easier, let me know!