摘要

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

理由

目前，Windows 和 OS X 的 Python 二进制扩展的发布很简单。开发人员和打包人员构建 Wheel（PEP 427，PEP 491），这些 Wheel 被分配了平台标签，如 win32 或 macosx_10_6_intel，然后将其上传到 PyPI。用户可以使用 pip 等工具下载和安装这些 Wheel。

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

使用 PEP 425 平台标签的构建工具不会跟踪有关特定 Linux 发行版或已安装系统库的信息，而是将所有 Wheel 分配过于模糊的 linux_i686 或 linux_x86_64 标签。由于这种歧义，没有理由期望在某台机器上编译的 linux 标签的构建发行版在另一台机器上能正常运行，出于这个原因，PyPI 不允许上传 Linux 的 Wheel。

理想情况下，Wheel 包的编译应该能够在任何 Linux 系统上运行。但是，由于 Linux 系统的巨大差异性——从 PC 到 Android 到具有自定义 libcs 的嵌入式系统，这在一般情况下无法保证。

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

基于从这些公司汲取的兼容性教训，我们定义了一个基本 manylinux1 平台标签，供二进制 Python Wheel 使用，并引入了初步工具的实现，以帮助构建这些 manylinux1 Wheel。

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

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

manylinux1 策略

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

• 应该仅依赖于一组极其有限的外部共享库；以及
• 应该仅依赖于这些外部共享库中的“旧”符号版本；以及
• 应该仅依赖于广泛兼容的内核 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] 系统上运行。

libcrypt.so.1 在 Fedora 30 发布后被从白名单中删除，因为 Fedora 30 使用的是 libcrypt.so.2。

由于 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 标准的 wheel。因此，我们不会尝试更改 pip wheel / bdist_wheel 的默认行为：它们将继续生成常规的 linux_* 平台标签，希望使用它们生成带有 manylinux1 标签的 wheel 的开发人员将不得不更改标签作为第二步的后处理步骤。

为了支持符合 manylinux1 标准的 wheel 的编译，我们提供了两个工具的初始草稿。

Linux 上打包的 Wheel

虽然我们承认在 manylinux1 wheel 中处理第三方库依赖关系的许多方法，但我们认识到，manylinux1 策略鼓励捆绑外部依赖关系，这与许多 Linux 发行版的系统包管理器的一般包管理策略背道而驰 [14]，[15]。这样做最主要的目的是跨发行版兼容性。此外，PyPI 上的 manylinux1 wheel 与通过系统包管理器提供的 Python 软件包占据不同的位置。

本 PEP 中鼓励偏离一般 Linux 发行版解绑策略的决定，是基于以下考虑

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

本 PEP 中描述的模型最适合跨平台 Python 软件包，因为它意味着它们可以重复使用它们已经在为 Windows 和 OS X 创建静态 wheel 所做的很多工作。我们认识到，它对于可能更喜欢与 Linux 独有的包管理功能进行更紧密交互的 Linux 特定软件包来说并不理想，并且只关心针对一小组特定发行版。

安装程序的平台检测

上面，我们定义了轮子与 manylinux1 兼容意味着什么。这里我们讨论Python 安装与 manylinux1 兼容意味着什么。特别是，这对于像 pip 这样的工具在决定是否应该考虑安装带有 manylinux1 标签的轮子时很重要。

由于 manylinux1 配置文件已经被证明适用于数以千计的流行商业 Python 发行版用户，我们建议安装工具应该在假设系统是兼容的情况下出错，除非有明确的理由认为并非如此。

我们知道四种主要的潜在不兼容来源，这些来源很可能在实际中出现。

• 最终，在将来，可能存在与该配置文件不兼容的发行版（例如，如果配置文件中的某个库以向后不兼容的方式更改了其 ABI）。
• 过时的 Linux 发行版（例如 RHEL 4）。
• 不使用 glibc 的 Linux 发行版（例如 Alpine Linux，它基于 musl libc，或 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，因此尚不清楚真正需要哪些功能以及优先级排序。因此，我们将在这里延迟更完整的解决方案，以便在 Linux 获得更多平台标签时，再通过单独的 PEP 进行处理。

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

PyPI 支持

PyPI 应该允许上传包含 manylinux1 平台标签的轮子。PyPI 不应该试图正式验证包含 manylinux1 平台标签的轮子是否符合本文档中描述的 manylinux1 策略。此验证任务应留给其他工具（例如 auditwheel）单独开发。

被拒绝的方案

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

未来更新

我们预计，在将来某个时刻，将出现一个 manylinux2，它指定一个更现代的基线环境（可能基于 CentOS 6），并且有一天会出现 manylinux3 等等，但我们将延迟指定这些内容，直到我们对最初的 manylinux1 提案有更多经验。

参考文献

版权

本文档已进入公共领域。