This PEP proposes a new platform tag seriesmusllinux forbinary Python package distributions for a Python installation thatdepends on musl on a Linux distribution. The tag works similarly tothe “perennial manylinux” platform tags specified inPEP 600, buttargeting platforms based on musl instead.
With the wide use of containers, distributions such as Alpine Linux[alpine], have been gaining more popularity than ever. Many of thembased on musl[musl], a different libc implementation from glibc, andtherefore cannot use the existingmanylinux platform tags. Thismeans that Python package projects cannot deploy binary distributionson PyPI for them. Users of such projects demand build constraints fromthose projects, putting unnecessary burden on project maintainers.
According to the documentation, musl has a stable ABI, and maintainsbackwards compatibility[musl-compatibility][compare-libcs], so abinary compiled against an earlier version of musl is guaranteed torun against a newer musl runtime[musl-compat-ml]. Therefore, we usea scheme similar to the glibc-version-based manylinux tags, butagainst musl versions instead of glibc.
Logic behind the new platform tag largely followsPEP 600(“perennial manylinux”), and requires wheels using this tag makesimilar promises. Please refer toPEP 600 for more details onrationale and reasoning behind the design.
Themusllinux platform tags only apply to Python interpretersdynamically linked against the musl libc and executed on the runtimeshared library, on a Linux operating system. Statically linkedinterpreters or mixed builds with other libc implementations (such asglibc) are out of scope and not supported by platform tags defined inthis document. Such interpreters should not claim compatibility withmusllinux platform tags.
Tags using the new scheme will take the form:
musllinux_${MUSLMAJOR}_${MUSLMINOR}_${ARCH}This tag promises the wheel works on any mainstream Linux distributionthat uses musl version${MUSLMAJOR}.${MUSLMINOR}, following theperennial design. All other system-level dependency requirements relyon the community’s definition to the intentionally vague “mainstream”description introduced inPEP 600. A wheel may make use of newersystem dependencies when all mainstream distributions using thespecified musl version provide the dependency by default; once allmainstream distributions on the musl version ship a certain dependencyversion by default, users relying on older versions are automaticallyremoved from the coverage of thatmusllinux tag.
The musl version values can be obtained by executing the musl libcshared library the Python interpreter is currently running on, andparsing the output:
importreimportsubprocessdefget_musl_major_minor(so:str)->tuple[int,int]|None:"""Detect musl runtime version. Returns a two-tuple ``(major, minor)`` that indicates musl library's version, or ``None`` if the given libc .so does not output expected information. The libc library should output something like this to stderr:: musl libc (x86_64) Version 1.2.2 Dynamic Program Loader """proc=subprocess.run([so],stderr=subprocess.PIPE,text=True)lines=(line.strip()forlineinproc.stderr.splitlines())lines=[lineforlineinlinesifline]iflen(lines)<2orlines[0][:4]!="musl":returnNonematch=re.match(r"Version (\d+)\.(\d+)",lines[1])ifmatch:return(int(match.group(1)),int(match.group(2)))returnNone
There are currently two possible ways to find the musl library’slocation that a Python interpreter is running on, either with thesystemldd command[ldd], or by parsing thePT_INTERPsection’s value from the executable’s ELF header[elf].
Distributions using the tag make similar promises to those describedinPEP 600, including:
${MUSLMAJOR}.${MUSLMINOR} or later.${ARCH} matches the return value ofsysconfig.get_platform() on the host system, replacing period(.) and hyphen (-) characters with underscores (_), asoutlined inPEP 425 andPEP 427.Example values:
musllinux_1_1_x86_64# musl 1.1 running on x86-64.musllinux_1_2_aarch64# musl 1.2 running on ARM 64-bit.
The value can be formatted with the following Python code:
importsysconfigdefformat_musllinux(musl_version:tuple[int,int])->str:os_name,sep,arch=sysconfig.get_platform().partition("-")assertos_name=="linux"andsep,"Not a Linux"arch=arch.replace(".","_").replace("-","_")returnf"musllinux_{musl_version[0]}_{musl_version[1]}_{arch}"
It is recommended for Python package repositories, including PyPI, toaccept platform tags matching the following regular expression:
musllinux_([0-9]+)_([0-9]+)_([^.-]+)
Python package repositories may impose additional requirements toreject Wheels with known issues, including but not limited to:
musllinux_1_1 wheel containing symbols only available in musl1.2 or later.musllinux_9000_0).Such policies are ultimately up to individual package repositories.It is not the author’s intention to impose restrictions to themaintainers.
There are no backwards compatibility concerns in this PEP.
Past experience on themanylinux tag series shows this approachwould be too costly time-wise. The author feels the “works well withothers” rule both is more inclusive and works well enough in practice.
This document is placed in the public domain or under theCC0-1.0-Universal license, whichever is more permissive.
Source:https://github.com/python/peps/blob/main/peps/pep-0656.rst
Last modified:2025-02-01 08:55:40 GMT