[Bug]: the macOS ARM64 wheel references a missing dynamic library

[sbp]

Component

exarch-python (Python bindings)

Bug Description

Trying to install and use exarch on macOS with ARM64 fails:

$ uvx --from exarch python -c "import exarch"
Installed 1 package in 2ms
Traceback (most recent call last):
  File "<string>", line 1, in <module>
    import exarch
  File "/.../lib/python3.13/site-packages/exarch/__init__.py", line 1, in <module>
    from .exarch import *
ImportError: dlopen(/.../lib/python3.13/site-packages/exarch/exarch.abi3.so, 0x0002): Library not loaded: /opt/homebrew/opt/xz/lib/liblzma.5.dylib
  Referenced from: <77DA5F32-6C7C-3F49-B697-E5A405AD5F27> /.../lib/python3.13/site-packages/exarch/exarch.abi3.so
  Reason: tried: '/opt/homebrew/opt/xz/lib/liblzma.5.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew/opt/xz/lib/liblzma.5.dylib' (no such file), '/opt/homebrew/opt/xz/lib/liblzma.5.dylib' (no such file)

The reason is that the Python wheel assumes the existence of /opt/homebrew/opt/xz/lib/liblzma.5.dylib but I do not use Homebrew. Using otool -L gives:

exarch.abi3.so:
	@rpath/exarch.abi3.so (compatibility version 0.0.0, current version 0.0.0)
	/opt/homebrew/opt/xz/lib/liblzma.5.dylib (compatibility version 14.0.0, current version 14.2.0)
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1351.0.0)

Expected Behavior

import exarch should succeed, preferably using either a vendored dynamic library or a statically linked library.

Steps to Reproduce

See bug description above.

Code Example

Environment

$ uvx --version
uvx 0.7.12

It's presumably trying to get exarch 0.2.5 from PyPI.

Error Output / Logs

Severity

High - Major functionality broken

Security

• This is NOT a security vulnerability (for security issues, email security@bug-ops.com instead)

Checklist

• I have searched existing issues to ensure this is not a duplicate
• I have provided all requested information

[bug-ops]

Root cause: lzma-sys defaults to dynamic linking, picking up Homebrew's liblzma on macOS CI runners and embedding the absolute dylib path into the wheel. The wheel then fails on any system without Homebrew's xz.

Fix: Force static linking via lzma-sys's static feature - this compiles liblzma from bundled sources at build time, eliminating the runtime dependency entirely.

# Cargo.toml (workspace)
lzma-sys = { version = "0.1", features = ["static"] }

# crates/exarch-core/Cargo.toml
lzma-sys.workspace = true

Will submit a PR.

[bug-ops]

Root cause and fix are confirmed. The fix uses xz2 = { version = "0.1", features = ["static"] } instead of a direct lzma-sys workspace dependency - xz2's static feature already enables lzma-sys/static transitively, avoiding an unnecessary direct dep on an implementation detail