摘要

本 PEP 提议为 Python 包的构建分发（例如 Wheels）创建一个新的平台标签 manylinux1_{x86_64,i686}，其外部依赖项仅限于标准化的、受限的 Linux 内核和核心用户空间 ABI 子集。提议 PyPI 支持上传和分发带有此平台标签的 Wheels，并且 pip 支持在兼容的平台上下载和安装这些包。

基本原理

目前，Windows 和 OS X 的二进制 Python 扩展分发非常简单。开发者和打包者构建 Wheels（PEP 427, PEP 491），并为其分配 win32 或 macosx_10_6_intel 等平台标签，然后上传到 PyPI。用户可以使用 pip 等工具下载和安装这些 Wheels。

对于 Linux，情况则要复杂得多。通常，在一个 Linux 发行版上构建的已编译 Python 扩展模块无法在其他 Linux 发行版上运行，甚至在安装了不同系统库的同一 Linux 发行版上的不同机器上也无法运行。

使用 PEP 425 平台标签的构建工具不会跟踪有关特定 Linux 发行版或已安装系统库的信息，而是为所有 Wheels 分配过于笼统的 linux_i686 或 linux_x86_64 标签。由于这种歧义，无法保证在一个机器上编译的 linux 标记的已构建分发在另一台机器上能正常工作，因此 PyPI 不允许上传 Linux 的 Wheels。

理想情况下，我们可以构建能在 *任何* Linux 系统上运行的 Wheel 包。但是，由于 Linux 系统极大的多样性——从 PC 到 Android 再到具有自定义 libcs 的嵌入式系统——这通常无法保证。

相反，我们定义了一个内核+核心用户空间 ABI 的标准子集，该子集在实践中足够兼容，能够保证符合此标准的包在 *许多* Linux 系统上运行，包括当前普遍使用的几乎所有桌面和服务器发行版。我们知道这一点是因为有些公司一直在分发这种广泛可移植的预编译 Python 扩展模块到 Linux——例如 Enthought 的 Canopy [4] 和 Continuum Analytics 的 Anaconda [5]。

基于这些公司积累的兼容性经验，我们因此为二进制 Python Wheels 定义了一个基线 manylinux1 平台标签，并引入了初步工具的实现，以帮助构建这些 manylinux1 Wheels。

Linux 二进制不兼容性的主要原因

为了正确定义一个标准，以保证符合此规范的 Wheel 包能在 *许多* Linux 平台上运行，我们有必要了解那些经常阻止 Linux 上预编译二进制文件可移植性的根本原因。这两个主要原因是对用户系统中不存在的共享库的依赖，以及对 glibc 等某些核心库特定版本的依赖。

manylinux1 策略

因此，为了实现广泛的可移植性，Python Wheels

• 应仅依赖于极少数外部共享库；并且
• 应仅依赖于这些外部共享库中的“旧”符号版本；并且
• 应仅依赖于广泛兼容的内核 ABI。

为了有资格获得 manylinux1 平台标签，Python Wheel 必须同时满足 (a) 包含的二进制可执行文件和编译代码 *仅* 链接到以下列表中包含的 SONAME 的库

libpanelw.so.5
libncursesw.so.5
libgcc_s.so.1
libstdc++.so.6
libm.so.6
libdl.so.2
librt.so.1
libc.so.6
libnsl.so.1
libutil.so.1
libpthread.so.0
libresolv.so.2
libX11.so.6
libXext.so.6
libXrender.so.1
libICE.so.6
libSM.so.6
libGL.so.1
libgobject-2.0.so.0
libgthread-2.0.so.0
libglib-2.0.so.0

以及 (b) 可以在包含这些库的系统包管理器所提供版本的标准 CentOS 5.11 [6] 系统上运行。

在 Fedora 30 发布时使用 libcrypt.so.2 而不是 libcrypt.so.1 之后，libcrypt.so.1 被追溯性地从白名单中移除。

由于 CentOS 5 仅适用于 x86_64 和 i686 架构，这是当前 manylinux1 策略支持的唯一架构。

在基于 Debian 的系统上，这些库由以下软件包提供

libncurses5 libgcc1 libstdc++6 libc6 libx11-6 libxext6
libxrender1 libice6 libsm6 libgl1-mesa-glx libglib2.0-0

在基于 RPM 的系统上，这些库由以下软件包提供

ncurses libgcc libstdc++ glibc libXext libXrender
libICE libSM mesa-libGL glib2

此列表是通过检查 Canopy [4] 和 Anaconda [5] 发行版的外部共享库依赖项编译而成的，这两个发行版都包含大量最受欢迎的 Python 模块，并且已在实践中被证实能在广泛的真实 Linux 系统中运行。

上述许多允许的系统库使用符号版本控制方案来实现向后兼容。CentOS 5.11 版本中的这些库提供的最新符号版本是

GLIBC_2.5
CXXABI_3.4.8
GLIBCXX_3.4.9
GCC_4.2.0

因此，作为要求 (b) 的结果，任何依赖上述共享库中版本化符号的 Wheel，其依赖的符号版本只能是以下版本

GLIBC <= 2.5
CXXABI <= 3.4.8
GLIBCXX <= 3.4.9
GCC <= 4.2.0

以下建议是 2016 年 1 月相关讨论的结果 [7], [8]。

请注意，在我们下面的建议中，我们不建议 pip 或 PyPI 尝试检查和强制执行此策略的细节（正如它们不检查和强制执行现有平台标签 win32 的细节一样）。上述文本（a）作为对包构建者的建议，以及（b）作为当给定 Wheel 在某些系统上不起作用时分配责任的方法：如果它满足上述策略，那么这是规范或安装工具中的一个错误；如果它不满足上述策略，那么是 Wheel 中的一个错误。这种方法的一个有用结果是，它为我们提供了更多经验时进行进一步更新和调整的可能性，例如，我们可以有一个“manylinux 1.1”策略，它针对相同的系统并使用相同的 manylinux1 平台标签（因此不需要对 pip 或 PyPI 进行任何进一步的更改），但调整上面的列表以删除已证明有问题的库或添加已证明安全的库。

PKG-VERSION-cp27-cp27mu-manylinux1_x86_64.whl
                 ^^^^^^ Good!

PKG-VERSION-cp27-cp27m-manylinux1_x86_64.whl
                 ^^^^^ Okay!

PKG-VERSION-cp27-none-manylinux1_x86_64.whl
                 ^^^^ BAD! Don't do this!

兼容 Wheel 的编译

glibc、libgcc 和 libstdc++ 管理其符号版本的方式意味着，在实践中，大多数开发者用于日常工作的编译器工具链无法构建 manylinux1 兼容的 Wheels。因此，我们不尝试改变 pip wheel / bdist_wheel 的默认行为：它们将继续生成常规的 linux_* 平台标签，而希望使用它们生成 manylinux1 标记的 Wheels 的开发者将不得不在第二步后处理中更改标签。

为了支持构建符合 manylinux1 标准的 Wheels，我们提供了两个工具的初始草案。

Linux 上的捆绑 Wheel

虽然我们承认 manylinux1 Wheels 中处理第三方库依赖的多种方法，但我们认识到 manylinux1 策略鼓励捆绑外部依赖项，这种做法与许多 Linux 发行版系统包管理器的包管理策略背道而驰 [14], [15]。这样做的主要目的是跨发行版兼容性。此外，PyPI 上的 manylinux1 Wheels 占用了与系统包管理器提供的 Python 包不同的细分市场。

本 PEP 中鼓励偏离 Linux 发行版普遍的非捆绑策略的决定是基于以下顾虑

1. 在当今自动化的持续集成和部署流水线时代，发布新版本和更新依赖项比定义这些策略时更容易。
2. pip 用户仍然可以自由使用 "--no-binary" 选项，如果他们希望强制本地构建而不是使用预构建的 Wheel 文件。
3. 现代容器化部署和“不可变基础设施”模型的流行，无论如何在应用程序层已经进行了大量的捆绑。
4. 通过 PyPI 分发捆绑的 Wheels 目前是 Windows 和 OS X 的标准做法。
5. 本 PEP 并没有排除将来为特定 Linux 发行版提供更具针对性的二进制文件的可能性。

本 PEP 中描述的模型最适合跨平台 Python 包，因为它意味着它们可以重用大量工作，以创建静态的 Windows 和 OS X Wheels。我们认识到，对于更偏向于与 Linux 独特的包管理功能进行更紧密交互且只关心针对少数特定发行版的 Linux 特定包而言，该模型不够理想。

安装程序的平台检测

上面，我们定义了一个 *Wheel* 如何成为 manylinux1 兼容的。在这里，我们讨论一个 *Python 安装* 如何成为 manylinux1 兼容的。特别是，这对于 pip 等工具在决定是否应考虑安装 manylinux1 标记的 Wheels 时很重要。

由于 manylinux1 配置文件已被证明对数以万计的流行商业 Python 发行版用户有效，我们建议安装工具应倾向于假设一个系统 *是* 兼容的，除非有特定理由认为并非如此。

我们知道四种可能在实践中出现的潜在不兼容的主要来源

• 最终，在未来，可能会出现破坏与此配置文件兼容性的发行版（例如，如果配置文件中的某个库更改其 ABI 而不向后兼容）
• 过旧的 Linux 发行版（例如 RHEL 4）
• 不使用 glibc 的 Linux 发行版（例如基于 musl libc 的 Alpine Linux，或 Android）

为了解决这些问题，我们提出一个两管齐下的方法。为了处理未来潜在的不兼容性，我们标准化了一个机制，供 Python 发行版明确表示某个 Python 安装是否肯定兼容或不兼容 manylinux1：这是通过安装一个名为 _manylinux 的模块，并设置其 manylinux1_compatible 属性来完成的。我们不建议将任何此类模块添加到标准库——这只是一个知名的名称，发行版和安装工具可以通过它来汇合。但是，如果发行版确实添加了这个模块，*它们应该将其添加到标准库*，而不是添加到 site-packages/ 目录，因为标准库会被虚拟环境继承（这是我们想要的），而 site-packages/ 通常不会。

然后，为了处理现有 Python 发行版最后两种情况，我们建议一种简单可靠的方法来检查 glibc 的存在和版本（基本上将其用作发行版整体年龄的“时钟”）。

具体来说，我们提议的算法是

def is_manylinux1_compatible():
    # Only Linux, and only x86-64 / i686
    from distutils.util import get_platform
    if get_platform() not in ["linux-x86_64", "linux-i686"]:
        return False

    # Check for presence of _manylinux module
    try:
        import _manylinux
        return bool(_manylinux.manylinux1_compatible)
    except (ImportError, AttributeError):
        # Fall through to heuristic check below
        pass

    # Check glibc version. CentOS 5 uses glibc 2.5.
    return have_compatible_glibc(2, 5)

def have_compatible_glibc(major, minimum_minor):
    import ctypes

    process_namespace = ctypes.CDLL(None)
    try:
        gnu_get_libc_version = process_namespace.gnu_get_libc_version
    except AttributeError:
        # Symbol doesn't exist -> therefore, we are not linked to
        # glibc.
        return False

    # Call gnu_get_libc_version, which returns a string like "2.5".
    gnu_get_libc_version.restype = ctypes.c_char_p
    version_str = gnu_get_libc_version()
    # py2 / py3 compatibility:
    if not isinstance(version_str, str):
        version_str = version_str.decode("ascii")

    # Parse string and check against requested version.
    version = [int(piece) for piece in version_str.split(".")]
    assert len(version) == 2
    if major != version[0]:
        return False
    if minimum_minor > version[1]:
        return False
    return True

已拒绝的替代方案：我们还考虑使用配置文件，例如 /etc/python/compatibility.cfg。问题在于，单个文件系统可能包含许多不同的解释器环境，每个环境都有自己的 ABI 配置文件——系统安装的 x86_64 CPython 的 manylinux1 兼容性可能无法告诉我们用户安装的 i686 PyPy 的 manylinux1 兼容性。将此配置信息放在 Python 环境本身内，可以确保它附属于正确的二进制文件，并大大简化查找代码。

我们还考虑使用更复杂的结构，例如一个应被视为兼容的所有平台标签列表，以及它们的偏好顺序，例如：_binary_compat.compatible = ["manylinux1_x86_64", "centos5_x86_64", "linux_x86_64"]。然而，这带来了一些复杂性。例如，我们希望能够区分“不支持 manylinux1”（或最终 manylinux2 等）的状态与“不明确是支持 manylinux1”的状态，这在上述表示中并不完全清楚；而且，考虑到目前唯一可能的平台标签是 manylinux1 和 linux，那么到底需要哪些功能来确定偏好顺序，这一点并不十分清楚。因此，我们推迟了更完整的解决方案，留待单独的 PEP，在 Linux 拥有更多平台标签时/如果需要的话。

对于库兼容性检查，我们也考虑了更复杂的检查（例如，检查内核版本，搜索并检查 manylinux1 配置文件中列出的所有单个库的版本等），但最终认为这比实际帮助用户更容易引入令人困惑的错误。（例如：不同的发行版在实际放置这些库的位置上有所不同，如果我们的检查代码未能使用正确的路径搜索，则很容易返回不正确的结果。）

PyPI 支持

PyPI 应允许上传包含 manylinux1 平台标签的 Wheels。PyPI 不应尝试正式验证包含 manylinux1 平台标签的 Wheels 是否符合本文档所述的 manylinux1 策略。此验证任务应留给其他工具，如 auditwheel，这些工具是单独开发的。

被拒绝的替代方案

一种替代方法是为每个 Linux 发行版（及其每个版本）提供单独的平台标签，例如 RHEL6，ubuntu14_10，debian_jessie 等。本提案中没有任何内容排除将来添加此类平台标签的可能性，或扩展 Wheel 元数据以允许 Wheels 声明对外部系统安装的包的依赖。然而，这些扩展需要比本提案多得多的工作量，并且包开发者仍可能不赞成，因为他们不愿意维护多个构建环境并构建多个 Wheels 以覆盖所有常见的 Linux 发行版。因此，我们认为此类提案超出了本 PEP 的范围。

未来更新

我们预计在未来的某个时候，会有一个 manylinux2，指定一个更现代化的基线环境（可能基于 CentOS 6），以及将来某个时候的 manylinux3 等等，但我们将其指定推迟到我们对初始 manylinux1 提案有更多经验之后。

参考资料

版权

本文档已进入公共领域。