Hi everyone,
I would like to start a discussion on what is still missing, and what would be required, to make loongarch64 a well-supported and standardized platform in the Python packaging ecosystem (PyPI / manylinux / musllinux). The long-term goal would be to reach what could be considered first-class support, meaning a platform with officially defined tags, upstream tool support, and reproducible build environments.
From the loongarch64 community side, much of the low-level infrastructure is already in place. We would like guidance on the expected and recommended path toward upstream and standardized support within PyPA.
Current status
From the perspective of tooling and operating system support, loongarch64 has reached a reasonably mature state.
Build and tooling infrastructure
CI and emulation
loongarch64 can already be emulated in CI environments via docker/setup-qemu-action.
Core packaging tools
Key tools in the Python packaging workflow, including patchelf, swig, uv, and auditwheel, support loongarch64.
Cross-build environments
Community-maintained manylinux-cross and musllinux-cross environments are available for loongarch64.
Operating system support
glibc-based environments
loongarch64 is supported by several glibc-based Linux environments that provide the ABI and runtime components typically required by the manylinux specification.
musl-based environments
Alpine Linux officially supports loongarch64 and maintains container images, although official Docker Hub images are not yet published.
CPython status
- loongarch64 support has been upstreamed into CPython.
- Python â„ 3.12 recognizes the GNU triplet without requiring downstream patches.
Gaps towards standardized integration
Despite the above progress, loongarch64 is not yet a first-class target in the official Python packaging workflow.
Upstream build tooling
Building wheels for loongarch64 currently relies on manylinux/musllinux images maintained by the loongarch64 community, as well as patched or forked versions of cibuildwheel. Upstreaming this support would significantly improve accessibility for package maintainers.
Availability of manylinux build roots
While there are glibc-based environments on loongarch64 that appear to meet the technical requirements of PEP 600, there is currently a lack of publicly available, long-term-maintained container images that can serve as reproducible manylinux build roots for this architecture. This gap makes it difficult to evaluate, standardize, and upstream loongarch64 support, even when the underlying ABI and runtime requirements are satisfied.
manylinux / musllinux platform definitions
loongarch64 is not yet included in the official manylinux or musllinux platform tags defined by existing PEPs, which prevents PyPI from recognizing loongarch64 wheels as official artifacts.
Topics for discussion
We would greatly appreciate guidance from the community on the following questions:
- What is the recommended path to introduce loongarch64 into the official manylinux and/or musllinux specifications (PEPs)?
- Would it be acceptable for the loongarch64 community to provide and maintain a reference manylinux build root for evaluation purposes, based on a glibc environment that meets the requirements of PEP 600?
- Are there specific technical or policy prerequisites from the PyPA side for accepting a new architecture?
- What level of CI maturity or hardware availability is typically expected before upstream adoption?
We are keen to collaborate and continue maintaining the necessary tooling, with the goal of moving loongarch64 from âcommunity-supportedâ to âofficially standardizedâ status.
Any feedback or pointers would be very welcome.