摘要

本 PEP 提出了一个方案，用于定义新的“manylinux” wheel 标签，而无需为每个特定标签都提交一个 PEP，类似于 Windows 和 macOS 标签的运作方式。这将允许包维护者更快地利用新标签，同时更好地利用有限的志愿者时间。

非目标包括：处理非 glibc 平台；与外部包管理器集成或处理外部依赖项（如 CUDA）；使 manylinux 标签比其 Windows/macOS 等效标签更复杂；除了采用我们现有经过验证的方法并对其进行简化之外的任何其他操作。这些都是重要问题，其他 PEP 未来可能会解决它们，但对于本 PEP 而言，它们不在范围之内。

基本原理

Python 用户喜欢 PyPI 上为其平台提供预编译包，因为这使得安装快速而简单。但在 Linux 上分发预编译二进制文件具有挑战性，因为基于 Linux 的平台种类繁多。例如，Debian、Android 和 Alpine 都使用 Linux 内核，但用户空间库截然不同，这使得创建在所有三个平台上都能工作的单个 wheel 变得困难或不可能。这种复杂性导致了许多以前关于 Linux wheel 的讨论停滞不前。

“manylinux”项目通过采取一种无情实用主义的策略取得了成功。我们选择了一组庞大但易于处理的 Linux 平台——具体来说，是主流的基于 glibc 的发行版，如 Debian、OpenSuSE、Ubuntu、RHEL 等——然后我们不惜一切代价制作能在所有这些平台上工作的 wheel。

这种方法需要许多折衷。Manylinux wheel 只能依赖于维护一致 ABI 并在所有这些发行版上普遍可用的外部库，这实际上将它们限制在一小组核心库（如 glibc 和少数其他库）中。Wheel 必须在精心挑选的最古老的平台上构建，使用本身在精心挑选的配置中构建的 Python。其他共享库依赖项必须捆绑到 wheel 中，这需要一个复杂的过程来避免不相关 wheel 之间的冲突。最后，这些要求的细节会随着时间的推移而变化，因为新的发行版会发布，旧的发行版会停止使用。

事实证明，这些要求并不太繁重：它们本质上与分发 Windows 或 macOS wheel 所必须做的事情相同，而且 manylinux 方法在包维护者和最终用户中都取得了显著的普及。但任何 manylinux PEP 都需要某种方式来解决这些复杂性。

在以前的 manylinux PEP 中（PEP 513、PEP 571、PEP 599），我们通过尝试在 PEP 中写下我们认为会使 wheel 在所有主流基于 glibc 的 Linux 系统上工作的确切库集、符号版本、Python 配置等来做到这一点。但这造成了几个问题。

首先，PEP 通常被认为是规范性参考：如果软件不符合 PEP，那么我们就修复软件。但在这种情况下，PEP 试图描述 Linux 发行版，它们是一个不断变化的目标，并且不认为我们的 PEP 限制了它们的行为。这意味着我们承担了一项无限期的承诺，即每当 Linux 发行版格局发生变化时，都要不断更新每个 manylinux PEP。对于无资金资助的志愿者来说，这是一项巨大的承诺，而且尚不清楚这项工作是否为我们的用户创造了价值。

其次，每次我们将 manylinux 推向更新的支持平台范围，或者添加对新架构的支持时，我们都必须经历一个相当复杂的过程：编写新的 PEP，更新 PyPI 和 pip 代码库以识别新标签，等待新的 pip 传播给用户等。这些在 Windows/macOS 上都不会发生；这只是 Linux 维护者的负担。这减缓了新 manylinux 版本的部署，并消耗了我们社区有限的 PEP 审查带宽，从而减缓了整个 Python 打包生态系统的进展。这对于不太流行的架构尤其成问题，它们拥有更少的志愿者资源来克服这些障碍。

我们该如何解决这个问题？

Manylinux PEP 必须面向三个主要受众

• 像 pip 这样的包安装器需要能够确定哪些 wheel 标签与它们运行的系统兼容。这需要一些自动化过程来内省系统并将其与 wheel 标签匹配。
• 像 PyPI 这样的包索引需要能够验证哪些 wheel 标签是有效的。通常，这只需要一个有效标签列表或它们匹配的正则表达式，而无需了解单个标签的实际语义。（但请参阅下面的上传验证讨论。）
• 包维护者需要能够构建符合给定 wheel 标签要求的 wheel。

这是本新 PEP 背后的关键见解：重要的是，不同的包安装器和包索引都同意哪些 manylinux 标签有效以及它们安装在哪些系统上，因此我们需要一个 PEP 来指定这些——但是，这些是简单的，并且在 manylinux 版本之间没有真正变化。不断变化的复杂部分是实际构建 wheel 的过程——但是，如果存在多个相互竞争的构建环境，只要它们都生成在最终用户系统上工作的 wheel，那么它们是否使用完全相同的规则就不重要。因此，我们不需要一个用于构建 wheel 的互操作性标准，所以我们不需要将细节写入 PEP。

为了进一步确信这种方法会奏效，让我们再次看看我们如何处理 Windows 和 macOS 上的 wheel：PEP 描述了哪些标签有效，以及它们应该在哪些系统上工作，但没有描述如何实际为这些平台构建 wheel。实际上，如果您想分发 Windows 或 macOS wheel，您可能需要经历一些复杂且文档不全的繁琐过程才能捆绑依赖项、定位正确的操作系统版本范围等。但该系统有效，改进它的方法是编写更好的文档和构建更好的工具；没有人认为让 Windows wheel 更好地工作的方法是发布一个 PEP，描述我们认为 Microsoft 应该在其库中包含哪些符号以及它们的链接器应该如何工作。本 PEP 将这种理念也扩展到 manylinux。

规范

manylinux_2_17_x86_64

manylinux_${GLIBCMAJOR}_${GLIBCMINOR}_${ARCH}

LEGACY_ALIASES = {
    "manylinux1_x86_64": "manylinux_2_5_x86_64",
    "manylinux1_i686": "manylinux_2_5_i686",
    "manylinux2010_x86_64": "manylinux_2_12_x86_64",
    "manylinux2010_i686": "manylinux_2_12_i686",
    "manylinux2014_x86_64": "manylinux_2_17_x86_64",
    "manylinux2014_i686": "manylinux_2_17_i686",
    "manylinux2014_aarch64": "manylinux_2_17_aarch64",
    "manylinux2014_armv7l": "manylinux_2_17_armv7l",
    "manylinux2014_ppc64": "manylinux_2_17_ppc64",
    "manylinux2014_ppc64le": "manylinux_2_17_ppc64le",
    "manylinux2014_s390x": "manylinux_2_17_s390x",
}

def manylinux_tag_is_compatible_with_this_system(tag):
    # Normalize and parse the tag
    tag = LEGACY_ALIASES.get(tag, tag)
    m = re.match("manylinux_([0-9]+)_([0-9]+)_(.*)", tag)
    if not m:
        return False
    tag_major_str, tag_minor_str, tag_arch = m.groups()
    tag_major = int(tag_major_str)
    tag_minor = int(tag_minor_str)

    if not system_uses_glibc():
        return False
    sys_major, sys_minor = get_system_glibc_version()
    if (sys_major, sys_minor) < (tag_major, tag_minor):
        return False
    sys_arch = get_system_arch()
    if sys_arch != tag_arch:
        return False

    # Check for manual override
    try:
        import _manylinux
    except ImportError:
        pass
    else:
        if hasattr(_manylinux, "manylinux_compatible"):
            result = _manylinux.manylinux_compatible(
                tag_major, tag_minor, tag_arch,
            )
            if result is not None:
                return bool(result)
        else:
            if (tag_major, tag_minor) == (2, 5):
                if hasattr(_manylinux, "manylinux1_compatible"):
                    return bool(_manylinux.manylinux1_compatible)
            if (tag_major, tag_minor) == (2, 12):
                if hasattr(_manylinux, "manylinux2010_compatible"):
                    return bool(_manylinux.manylinux2010_compatible)

    return True

被拒绝的替代方案

继续 manylinux20XX 系列：如上所述，这导致新版本的推出需要更多的精力、更慢且更复杂。虽然最初看起来在两个地方有一些补偿性的好处，但如果仔细观察，事实并非如此。

首先，这迫使我们在 PEP 的文本中提供关于 Linux 发行版如何工作的人类可读描述。但这并没有最初看起来那么有价值，而且通过新的“常青”方法也可以更好地处理。

如果您正在尝试构建 wheel，您最需要的是关于如何使用构建镜像及其工具的教程。如果您正在尝试添加对新构建配置文件的支持或创建 auditwheel 的竞争对手，那么您最好的资源将是 auditwheel 源代码和问题跟踪器，它们总是比用英文编写且没有测试的摘要规范更详细、更精确、更可靠。像旧的 manylinux20XX PEP 这样的文档确实增加了价值！但在两种情况下，它主要作为提供概述和上下文的次要参考。

此外，PEP 流程不适合维护这种参考文档——我们不将 pip 用户手册保存在 PEP 存储库中是有原因的！auditwheel 维护者最能理解哪种文档对他们的用户有用，并能够长期维护这些文档。例如，不同的 manylinux 版本之间存在大量重叠，而 PEP 流程目前迫使我们通过在不断增长的文档列表中复制粘贴所有内容来处理这个问题；相反，auditwheel 维护者可以选择将共同部分分解到一份共享文档中。

一个相关的问题是，使用常青方法，包维护者可能更难决定要针对哪个构建配置文件：他们不再需要在 manylinux1、manylinux2010、manylinux2014 等之间进行选择，而是有更多的选项，如 manylinux_2_5、manylinux_2_6、……、manylinux_2_20 等。但我们仍然不认为这在实践中会成为问题。在这两种系统中，大多数包维护者都不会从阅读 PEP 并尝试从头开始实现它们。如果您是一位特别专业且雄心勃勃的包维护者，需要针对新版本或新架构，常青方法为您提供了额外的灵活性。但对于普通的日常维护者，我们预计他们会从像 packaging.python.org 这样的教程开始，并从现有构建镜像中进行选择。教程可以像推荐 manylinux2014 一样轻松地推荐 manylinux_2_17，我们预计实际预提供的构建镜像在这两种情况下都是相同的。再次强调，通过在正确的位置维护这份文档，而不是试图在 PEP 存储库中进行，我们预计最终会得到更高质量、更符合目的的文档。

最后，一些参与者指出，能够明确判断一个 wheel 是否符合规范要求是非常好的。使用新的“常青”方法，我们永远无法 100% 确定一个 wheel 确实符合规范，因为这取决于 Linux 发行版。作为工程师，我们对这种不确定性有一种充分理由的不喜欢。

然而：如上面的例子所示，我们仍然可以明确地判断一个 wheel 不符合规范，这在实践中被证明是重要的。而且，在实践中，使用 manylinux20XX 方法，每当发行版更改时，我们实际上都会更改规范；这需要更长的时间。所以，即使一个 wheel 今天符合规范，明天也可能变得不符合规范。这令人沮丧，但不幸的是，如果您关心的是向用户分发可工作的 wheel，这种不确定性是不可避免的。

因此，即使在旧方法最初看起来有优势的这些方面，我们预计新方法实际上也会做得同样好甚至更好。

切换到常青标签，但继续为每个版本编写 PEP：这被提出作为一种混合方案，试图获得常青标签系统的一些优势——例如更容易推出新版本——同时保留 manylinux20XX 方案的优势，例如强制我们编写有关 Linux 发行版的文档，简化包维护者的选项，以及能够明确判断一个 wheel 是否符合规范。但如上所述，仔细观察后，事实证明这些优势在很大程度上是虚幻的。而且，这也继承了 manylinux20XX 方案的显著缺点，例如创建了无限期地更新不断增长的复制粘贴 PEP 列表的义务。

使 auditwheel 成为规范：另一个被考虑的可能性是使 auditwheel 成为 manylinux 定义的规范参考，即，一个 wheel 仅当 auditwheel check 完成而没有错误时才符合要求。这被拒绝了，因为打包 PEP 的目的是定义工具之间的互操作性，而不是认可特定工具。

在标签字符串中添加额外词语：我们考虑的另一个提议是在 wheel 标签中添加额外词语，例如 manylinux_glibc_2_17 而不是 manylinux_2_17。这样做的动机是为将来其他类型的版本控制启发式方法敞开大门——例如，我们可以有 manylinux_glibc_$VERSION 和 manylinux_alpine_$VERSION。

但是“manylinux”一直都是“与主流基于 glibc 的发行版广泛兼容”的同义词；将其用于与 alpine 等不相关的构建配置文件会造成更多的混淆而不是帮助。此外，一些不熟悉打包细节的早期审阅者发现 glibc 这个词具有误导性，他们很快得出结论，认为它意味着他们需要一个精确该 glibc 版本的系统。而像 manylinux_$VERSION 和 alpine_$VERSION 这样的标签也具有简洁和直接的优点。所以我们将采用这种方式。