摘要

本 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 2.7 作为他们的主要版本。这些用户为了参与更广泛的 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 都计划将其反向移植到他们的 2.7 运行时中。

自动调用

PEP 453 在 Makefile 和 Windows 和 OSX 安装程序中默认自动调用 ensurepip。这使得它能够确保默认情况下，所有用户都将获得已安装 pip 的 Python。但是，本 PEP 认为，虽然这对 Python 2.7 的 Windows 和 Mac OS X 安装程序来说很好，但对于一般的 Python 2.7 Makefile 来说不好。

Makefile 的主要使用者是下游包管理器，它们自己分发 Python。这些下游发行版通常不希望通过 ensurepip 安装 pip，而是希望最终用户使用他们自己的包管理器安装它。从 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。

参考文献

版权

本文档已进入公有领域。