Ensure wheel isn't restricted to specific interpreter version

[lukasIO]

additionally updates e2e tests to use built wheels directly, see #557

[theomonnom]

@codex Is hatch the right build system for this kind of project (native dependencies)?
Eitherway is there a way for us to not having to rewrite the platform tags logic

[chatgpt-codex-connector]

To use Codex here, create an environment for this repo.

[theomonnom]

@codex Is hatch the right build system for this kind of project (native dependencies)?
Eitherway is there a way for us to not having to rewrite the platform tags logic

[chatgpt-codex-connector]

Response

Short answer: Hatchling is a reasonable fit here because you’re not compiling a CPython extension; you’re bundling native shared libraries and shipping them as artifacts. The repo already uses a custom Hatch build hook to set platform tags appropriately for those native FFI assets, which is exactly the sort of customization hatchling supports. livekit-rtc/pyproject.tomlL1-L56 livekit-rtc/hatch_build.pyL1-L83

---

Why Hatchling is acceptable for native dependencies here

• The LiveKit RTC package uses hatchling as the build backend and configures artifacts (.so/.dylib/.dll) to be included in wheels, which works fine when the native bits are runtime-loaded via ctypes, not via the Python C API. livekit-rtc/pyproject.tomlL1-L56 livekit-rtc/hatch_build.pyL14-L26
• The custom hook explicitly marks the wheel as non-pure and sets a platform tag, which is the correct approach for bundling platform-specific shared libraries while staying py3-none-* compatible for Python 3.x. livekit-rtc/hatch_build.pyL32-L83

---

Avoiding “rewriting the platform tags logic”

You already have centralized, reusable logic for platform tag selection in livekit-rtc/hatch_build.py, and hatchling is calling it through the custom wheel hook configuration in pyproject.toml. That means you do not need to rewrite the logic—it’s already factored into one place and invoked by hatchling via tool.hatch.build.targets.wheel.hooks.custom. livekit-rtc/pyproject.tomlL41-L52 livekit-rtc/hatch_build.pyL32-L83

If you later change build systems, you can likely reuse the same helper logic from hatch_build.py (or extract it to a shared module) rather than rewriting it, since it’s already in one file and decoupled from other packaging code. livekit-rtc/hatch_build.pyL32-L83

---

Suggested next step

If the concern is portability or minimizing duplication:

• Consider extracting _get_platform_tag() (and helpers) into a small internal module so it can be used from other build systems without change; hatchling can keep calling it from the hook while any other tooling can import it as well. livekit-rtc/hatch_build.pyL32-L83

---

If you want, I can propose a small refactor to make the platform tag logic reusable across build backends (while keeping hatchling in place).

View task →

[theomonnom]

from sysconfig import get_platform

class bdist_wheel(_bdist_wheel):
    def finalize_options(self):
        self.plat_name = get_platform()  # force a platform tag
        _bdist_wheel.finalize_options(self)

you can use sysconfig

[lukasIO]

Unfortunately not anymore.

As the minimum deployment target for (FFI) macosx is no longer 10.9 (which according to AI is the min deployment target of python) but rather 10.15. (see https://github.com/livekit/python-sdks/actions/runs/21109309584/job/60705482927 for the failing run with defaults)This leads us to have to add platform parsing/adjustments also for setuptools.

[theomonnom]

otherwise lgtm