摘要

本 PEP 提议将由 PEP 453 添加到 Python 3.4 的 ensurepip 模块反向移植到 Python 2.7。它还提议将 ensurepip 的自动调用添加到 Python 2.7 的 Windows 和 OSX 安装程序中。然而，它不提议将自动调用添加到 Makefile 中。

它还提议更新包分发和安装指南的文档更改，使其与 3.4 中的内容匹配，其中提到了使用 ensurepip 模块来引导安装程序。

基本原理

Python 2.7 实际上是 Python 的一个 LTS 版本，代表着 2.x 系列的终结，并且仍有大量用户将其作为主要版本。这些用户为了参与更广泛的 Python 生态系统，必须手动尝试寻找正确的方式来引导打包工具。

本 PEP 认为，让最终用户尽可能容易地参与更广泛的 Python 生态系统对于以下 3 个主要原因很重要：

1. Python 2.x 到 3.x 的迁移存在许多痛点，这些痛点可以通过一些第三方模块（如 six [1]、modernize [2] 或 future [3]）来缓解。然而，依赖这些工具要求使用该项目的每个人都拥有一个安装这些包的工具。
2. 除了帮助从 Python 2.x 迁移到 3.x 的工具之外，Python 3 中还有许多新模块，PyPI 上提供了它们的反向移植。这也有助于人们编写 2.x 和 3.x 兼容的软件，并使他们能够在 Python 2 上使用 Python 3 的一些新功能。
3. 用户还需要许多工具来创建符合正在提出的新标准的 Python 包。像 setuptools [4]、Wheel [5] 和 twine [6] 这样的工具正在实现更安全、更快、更可靠的打包工具链。如果人们必须先被告知如何安装包管理器，那么这些工具可能很难使用。
4. Python 最大的优势之一在于其上构建的庞大库和项目生态系统，其中大部分通过 PyPI 分发。然而，为了有意义地受益于这个广泛的生态系统，最终用户（其中一些是新用户）需要决定他们应该获取哪个包管理器、如何获取它，然后最后实际安装它。

此外，Python 的替代实现正在认识到 PEP 453 的好处，PyPy 和 Jython 都计划将 ensurepip 反向移植到它们的 2.7 运行时。

自动调用

PEP 453 使得 ensurepip 在 Makefile 以及 Windows 和 OSX 安装程序中默认自动调用。这确保了默认情况下，所有用户都将获得预装 pip 的 Python。然而，本 PEP 认为，虽然这对于 Python 2.7 的 Windows 和 Mac OS X 安装程序来说没问题，但对于一般的 Python 2.7 Makefile 来说不可以。

Makefile 的主要消费者是自行分发 Python 的下游包管理器。这些下游分发商通常不希望 pip 通过 ensurepip 安装，并且更倾向于最终用户使用自己的包管理器安装它。不从 Makefile 自动调用 ensurepip 将允许这些分发商简单地忽略 ensurepip 已被反向移植的事实，并且仍然不会通过它安装 pip。

OSX 和 Windows 安装程序的主要消费者是试图在自己的机器上安装 Python 的最终用户。这些用户没有可用的包管理器可以通过更受支持的机制将 pip 安装到他们的 Python 中。因此，本 PEP 认为在 OSX 和 Windows 上默认安装是最佳行动方案。

文档

作为本 PEP 的一部分，Python 3.4 的更新打包分发和安装指南将被反向移植到 Python 2.7。

下游分发商禁用 ensurepip

由于其在 venv 模块中的使用，下游分发商无法在 Python 3.4 中禁用 ensurepip 模块。然而，由于 Python 2.7 没有这样的模块，因此明确允许下游分发商修补 ensurepip 模块以阻止它安装任何东西。

如果下游分发商希望在 Python 2.7 中完全禁用 ensurepip，他们仍然应该至少提供该模块并允许 python -m ensurepip 样式的调用。然而，它应该引发错误或以非零退出代码退出，并在 stderr 上打印错误，指导用户使用什么而不是 ensurepip。

参考资料

版权

本文档已置于公共领域。