用例

本 PEP 中的行为更改旨在尽可能地“做正确的事情”。在本节中，我们考虑本 PEP 为几个代表性用例/上下文指定的更改。具体来说，我们询问了本 PEP 可能更改的两种行为

1. 在实现本 PEP 之后，类似 pip install 的 Python 特定安装程序工具是否默认允许安装？
2. 如果确实运行了此类工具，它是否应该愿意删除该上下文中外部（非 Python 特定）包管理器提供的包，例如发行版包管理器？

（为简单起见，本节将 pip 作为 Python 特定的安装程序工具进行讨论，尽管分析应同样适用于任何其他 Python 特定的包管理工具。）

此表总结了下面详细讨论的用例

更详细地说，上述用例是

1. 标准的未修补 CPython，没有任何特殊的配置或对 sysconfig 的补丁，也没有标记文件。本 PEP 不会更改其行为。

   此类 CPython 应该（无论本 PEP 如何）不要以与同一系统上任何发行版安装的 Python 重叠的方式安装。例如，在将 Python 安装在 /usr/bin 中的操作系统上，不应该使用 ./configure --prefix=/usr 构建自定义 CPython 并安装，否则它将覆盖发行版的一些文件，并且发行版最终将覆盖安装中的一些文件。相反，安装应该在单独的目录中（可能是 /usr/local、/opt 或主目录）。

   因此，我们可以假设此类 CPython 拥有自己的 stdlib 目录和自己的 sysconfig 方案，这些方案不会与任何发行版安装的 Python 重叠。因此，任何操作系统安装的包在这里都不可见或不相关。

   如果在这种情况下存在“外部安装”包的概念，则它位于操作系统外部，通常由构建和安装此 CPython 的人管理。因为安装程序选择不添加标记文件或修改 sysconfig 方案，所以他们选择了当前的行为，并且 pip install 可以删除此 CPython 中可用的任何包。

2. 发行版的 /usr/bin/python3，无论以 root 身份运行 pip install 还是运行 pip install --user，都遵循我们的 发行版建议。

   这些建议包括在 stdlib 目录中提供标记文件，以默认防止 pip install，并将发行版提供的包放在默认 sysconfig 方案以外的位置，以便以 root 身份运行的 pip 不会写入该位置。

   许多发行版（包括 Debian、Fedora 及其衍生版本）已经在执行后者。

   在 Debian 及其衍生版本上，pip install 目前不会删除发行版安装的包，因为 Debian 附带了一个 阻止此操作的 pip 补丁。因此，对于这些发行版，本 PEP 不是行为更改；它只是以不再特定于 Debian 的方式标准化该行为，并且可以包含到上游 pip 中。

   （我们已经看到用户报告了 Debian 或其衍生版本中外部安装的包被删除。我们怀疑这是因为用户之前运行过 sudo pip install --upgrade pip，因此现在拥有了一个没有 Debian 补丁的 /usr/bin/pip 版本；在上游包安装程序中标准化此行为将解决此问题。）

3. 在虚拟环境（来自 venv 或 virtualenv）中使用时，发行版 Python。

   在虚拟环境中，所有包都由该环境拥有。即使将 pip、setuptools 等安装到环境中，它们也应该由特定于该环境的工具管理；它们不是系统管理的。

4. 在使用 --system-site-packages 的虚拟环境中使用时，发行版 Python。这与上一个案例类似，但值得明确指出，因为全局 sys.path 上的任何内容都是可见的。

   目前，“pip 是否会删除外部安装的包”的答案是否定的，因为 pip 针对在虚拟环境中运行并尝试删除外部包有一个特殊情况。在本 PEP 之后，答案仍然是否定的，但推理变得更通用：系统站点包将位于环境中用于包管理的任何 sysconfig 方案之外。

5. 当在单个应用程序容器镜像（例如 Docker 容器）中使用发行版 Python 时。在这种用例中，破坏系统软件的风险较低，因为通常容器中只运行单个应用程序，并且影响较小，因为您可以重建容器，并且不必费力地恢复正在运行的机器。此外，还存在大量带有未限定的 RUN pip install ... 语句等的现有 Dockerfile，最好不要破坏它们。因此，基础容器镜像的构建者可能希望确保标记文件不存在，即使底层操作系统默认情况下提供了一个。

   存在一个小的行为变化：目前，以 root 身份运行的 pip 会删除外部安装的包，但在此 PEP 之后将不会删除。我们不建议提供覆盖此行为的方法。但是，由于基础镜像通常是最小的，因此没有太多用例仅仅是为了卸载包（尤其是在不使用发行版自己的工具的情况下）。常见的情况是，当 pip 想要升级包时，它之前会删除旧版本（Debian 除外）。在此更改之后，旧版本仍将保留在磁盘上，但 pip 仍将覆盖外部安装的包，并且我们认为这足以避免在实践中成为破坏性更改 - Python import 语句仍然可以获取新安装的包。

   如果需要一种方法来执行此操作，我们建议发行版应记录安装工具访问发行版本身使用的 sysconfig 方案的方法。有关更多讨论，请参阅发行版建议部分。

   此 PEP 的作者认为，即使在单个应用程序容器镜像中，使用发行版安装的 Python 解释器的虚拟环境仍然是一个好主意。即使它们运行单个应用程序，该应用程序也可能运行由 Python 实现的操作系统命令，如果您使用 Python 特定的工具安装或升级了发行版提供的 Python 包，则这些命令可能会中断。

6. Conda 特别支持使用非 conda 工具（如 pip）来安装 Conda 存储库中不可用的软件。在这种情况下，Conda 充当外部包管理器/发行版，而 pip 充当 Python 特定的包管理器。

   从某种意义上说，这类似于第一种情况，因为 Conda 提供了它自己的 Python 解释器安装。

   我们认为此 PEP 不需要对 Conda 进行任何更改，并且已实现此 PEP 中更改的 pip 版本将在 Conda 环境中继续像现在一样运行。（也就是说，可能值得考虑是否为 pip 安装和 Conda 安装的软件使用单独的 sysconfig 方案，因为对于其他发行版来说，这是一个好主意。）

7. 对于“面向开发人员的发行版”，我们指的是一种特定类型的发行版，其中预期或鼓励发行版中 Python 或其他语言的直接用户在希望添加库时对发行版本身进行更改。常见示例包括软件开发公司中的私有“monorepos”，其中单个存储库构建第三方和内部软件，并且发行版 Python 解释器的直接用户通常是编写上述内部软件的软件开发人员。像Nixpkgs这样的用户级包管理器也可能算在内，因为它们鼓励作为 Python 开发人员的 Nix 用户为 Nix 打包他们的软件。

   在这些情况下，发行版可能希望通过提供指导来响应尝试进行的 pip install，鼓励使用发行版自己的工具添加新包，并提供文档链接。

   如果发行版支持/鼓励从发行版的 Python 解释器创建虚拟环境，则可能还存在有关如何正确设置虚拟环境的自定义说明（例如 Nixpkgs 所做的那样）。

8. 在为发行版 Python 构建发行版 Python 包时（情况 2），将 pip install 用作发行版包构建过程的一部分可能很有用。（例如，考虑使用 pip install . 在 xyz 的 sdist/源代码包中构建 python-xyz RPM。）发行版可能还希望使用更具针对性但仍然是 Python 特定的安装工具，例如installer。

   对于这种情况，构建过程需要找到某种方法来抑制标记文件以允许 pip install 工作，并且可能需要将 Python 特定的工具指向发行版的 sysconfig 方案而不是提供的默认方案。有关如何实现此操作的更多讨论，请参阅发行版建议部分。

   由于此 PEP 的结果，pip 将不再能够删除系统上已有的包。但是，此行为更改是可以的，因为包构建过程不应（并且通常无法）包含删除系统上其他一些文件的指令；它只能打包它自己的文件。

9. 使用 PYTHONHOME 设置备用 Python 环境（而不是虚拟环境）的发行版 Python（与虚拟环境相反），其中 PYTHONHOME 设置为直接从发行版 Python 复制的某个目录（例如，cp -a /usr/lib/python3.x pyhome/lib）。

   假设没有修改，则行为就像底层发行版 Python（情况 2）一样。因此存在行为更改 - 您不再能够默认使用 pip install，并且如果您覆盖它，它将不再删除外部安装的包（即从操作系统复制并位于操作系统管理的 sys.path 条目中的 Python 包）。

   这种行为更改似乎是合理的，因为如果您的 PYTHONHOME 是发行版 Python 的直接副本，则它应该像发行版的 Python 一样运行。

10. 使用从兼容的未修改的上游 Python 获取的 PYTHONHOME 的发行版 Python（或任何 Python 解释器）。

    由于此 PEP 中的行为更改以标准库中的文件（stdlib 中的标记文件和 sysconfig 模块的行为）为关键，因此行为就像未修改的上游 CPython（情况 1）一样。

将解释器标记为使用外部包管理器

在 Python 特定的包安装程序（即 pip 等工具 - 而不是 apt 等外部工具）将包安装到某个 Python 上下文之前，它应该默认执行以下检查

1. 它是否在虚拟环境之外运行？它可以通过 sys.prefix == sys.base_prefix 来确定这一点（但请参阅向后兼容性）。
2. 在由 sysconfig.get_path("stdlib", sysconfig.get_default_scheme()) 标识的目录中是否存在 EXTERNALLY-MANAGED 文件？

如果这两个条件都为真，则安装程序应退出并显示错误消息，指示在虚拟环境之外禁用对此 Python 解释器的目录中的包安装。

安装程序应该有一种方法允许用户覆盖这些规则，例如命令行标志 --break-system-packages。此选项不应默认启用，并且应带有其使用存在风险的含义。

EXTERNALLY-MANAGED 文件是一个 INI 样式的元数据文件，旨在由标准库configparser 模块解析。如果该文件可以使用 UTF-8 编码由 configparser.ConfigParser(interpolation=None) 解析，并且它包含一个节 [externally-managed]，则安装程序应查找文件中指定的错误消息并将其作为错误的一部分输出。如果由 locale.getlocale(locale.LC_MESSAGES) 返回的元组的第一个元素（即语言代码）不是 None，则它应查找名为 Error- 后跟语言代码的键的值。如果该键不存在，并且如果语言代码包含下划线或连字符，则它应查找名为 Error- 后跟语言代码下划线或连字符之前部分的键。如果它找不到这两个键中的任何一个，或者如果语言代码是 None，则它应查找名为 Error 的键。

如果安装程序在文件中找不到错误消息（因为文件无法解析或因为不存在合适的错误键），则安装程序应仅使用其自己的预定义错误消息，该消息应建议用户创建一个虚拟环境来安装包。

软件发行版如果有一个非 Python 特定的包管理器来管理其 Python 包的 sys.path 中的库，则通常应在其标准库目录中提供一个 EXTERNALLY-MANAGED 文件。例如，Debian 可能会在 /usr/lib/python3.9/EXTERNALLY-MANAGED 中提供一个文件，其内容类似于

[externally-managed]
Error=To install Python packages system-wide, try apt install
 python3-xyz, where xyz is the package you are trying to
 install.

 If you wish to install a non-Debian-packaged Python package,
 create a virtual environment using python3 -m venv path/to/venv.
 Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
 sure you have python3-full installed.

 If you wish to install a non-Debian packaged Python application,
 it may be easiest to use pipx install xyz, which will manage a
 virtual environment for you. Make sure you have pipx installed.

 See /usr/share/doc/python3.9/README.venv for more information.

这为尝试安装包的用户提供了有用且与发行版相关的信息。可选地，可以在同一文件中提供翻译

Error-de_DE=Wenn ist das Nunstück git und Slotermeyer?

 Ja! Beiherhund das Oder die Virtualenvironment gersput!

在某些上下文中，例如创建后不再更新的单个应用程序容器镜像，发行版可以选择不提供 EXTERNALLY-MANAGED 文件，以便用户可以安装他们想要的任何内容（就像他们今天可以做的那样）而不必手动覆盖此规则。

仅写入目标 sysconfig 方案

通常，Python 包安装程序安装到由 sysconfig 标准库包返回的方案中的目录。通常，这是由 sysconfig.get_default_scheme() 返回的方案，但基于配置（例如 pip install --user），它可能会使用不同的方案。

无论何时安装程序安装到 sysconfig 方案中，此 PEP 都规定安装程序绝不应修改或删除该方案之外的文件。例如，如果它正在升级包，并且该包已安装在该方案之外的目录中（可能在来自另一个方案的目录中），则它应保留现有文件。

如果安装程序最终在升级期间覆盖了现有安装，我们建议它在运行结束时发出警告。

如果安装程序安装到 sysconfig 方案之外的位置（例如，pip install --target），则本小节不适用。

将安装标记为外部管理

发行版应在其 stdlib 目录中创建一个 EXTERNALLY-MANAGED 文件。

引导用户使用虚拟环境

该文件应包含一条有用且与发行版相关的错误消息，指示如何通过发行版的包管理器安装系统范围的包以及如何设置虚拟环境。如果您的发行版经常被用户在 python3 命令可用（尤其是在 pip 或 get-pip 可用）但 python3 -m venv 不起作用的状态下使用，则消息应清楚地指示如何使 python3 -m venv 正确工作。

考虑打包 pipx（一种用于安装 Python 语言应用程序的工具），并在错误中建议使用它。pipx 自动为该应用程序单独创建一个虚拟环境，这对于想要安装一些 Python 语言软件（发行版中没有提供）但本身不是 Python 用户的最终用户来说是一个更好的默认选项。在发行版中打包 pipx 可以避免这样一种讽刺：指示用户使用 pip install --user --break-system-packages pipx 来避免破坏系统包。考虑安排以下事项：您的发行版为最终用户提供的 Python 包/环境（例如，Fedora 上的 python3 或 Debian 上的 python3-full）依赖于 pipx。

在容器镜像中保留标记文件

为单应用程序容器生成官方镜像的发行版（例如，Docker 容器镜像）应保留 EXTERNALLY-MANAGED 文件，最好以一种即使镜像用户在其镜像中安装了包更新也不会消失的方式（想想 RUN apt-get dist-upgrade）。

创建单独的发行版和本地目录

发行版应在系统解释器的 sys.path 上放置两条独立的路径，一条用于发行版安装的包，另一条用于本地系统管理员安装的包，并配置 sysconfig.get_default_scheme() 指向后一条路径。这确保了像 pip 这样的工具不会修改发行版安装的包。本地系统管理员的路径应位于 sys.path 上的发行版路径之前，以便本地安装优先于发行版包。

例如，Fedora 和 Debian（及其衍生产品）都通过使用 /usr/local 用于本地安装的包和 /usr 用于发行版安装的包来实现这种拆分。Fedora 使用 /usr/local/lib/python3.x/site-packages 与 /usr/lib/python3.x/site-packages。（Debian 使用 /usr/local/lib/python3/dist-packages 与 /usr/lib/python3/dist-packages 作为与本地编译的 Python 解释器进一步分离的层：如果您在 /usr/local/bin 中构建和安装上游 CPython，它将查看 /usr/local/lib/python3/site-packages，并且 Debian 希望确保通过本地构建的解释器安装的包不会出现在发行版解释器的 sys.path 上。）

请注意，/usr/local 与 /usr 的拆分类似于 PATH 环境变量通常包含 /usr/local/bin:/usr/bin 并且非发行版软件默认安装到 /usr/local 的方式。这种拆分 由文件系统层次结构标准推荐。

您可以通过两种方式做到这一点。一种是，如果您正在直接构建和打包 Python 库（例如，您的打包助手解压缩一个 PEP 517 构建的 wheel 或调用 setup.py install），则安排这些工具使用不在 sysconfig 方案中但仍在 sys.path 上的目录。

另一种是在包构建中运行时与在已安装的系统上运行时安排默认 sysconfig 方案发生变化。bpo-43976 中的 sysconfig 自定义挂钩应该使这变得容易（一旦被接受并实现）：让您的打包工具设置环境变量或其他可检测的配置，并定义一个 get_preferred_schemes 函数，以便在从包构建内部调用时返回不同的方案。然后，您可以在发行版打包过程中使用 pip install。

我们建议添加一个 --scheme=... 选项来指示 pip 对特定方案运行。（有关 pip 当前如何确定方案，请参见下面的 实现说明。）一旦该选项可用，为了进行本地测试以及可能进行实际打包，您将能够运行类似 pip install --scheme=posix_distro 的命令来明确地将包安装到您的发行版位置（绕过 get_preferred_schemes）。如果绝对需要，还可以使用 pip uninstall --scheme=posix_distro 使用 pip 从系统管理目录中删除包，这解决了 基本原理 中用例 5 中（希望是理论上的）回归。

要使用 pip 安装包，您还需要要么抑制 EXTERNALLY-MANAGED 标记文件以允许 pip 运行，要么在命令行上覆盖它。您可能希望在构建 chroot 中使用与在容器镜像中相同的方法来抑制标记文件。

将这些设置成自动化的优点（在您的构建环境中抑制标记文件并让 get_preferred_schemes 自动返回您的发行版的方案）在于，未修饰的 pip install 将在包构建内部工作，这通常意味着碰巧在内部调用 pip install 的未修改的上游构建脚本将执行正确操作。当然，您也可以确保您的打包过程始终调用 pip install --scheme=posix_distro --break-system-packages，这也可以工作。

这里最好的方法在很大程度上取决于您发行版的约定和打包机制。

类似地，不是用于可导入 Python 代码的 sysconfig 路径 - 即 include、platinclude、scripts 和 data - 也应该有两个变体，一个用于发行版打包的软件，另一个用于本地安装的软件，并且发行版应设置为两者都可用。例如，一个典型的符合 FHS 的发行版将使用 /usr/local/include 作为默认方案的 include 和 /usr/include 作为发行版打包的头文件并将两者都放在编译器的搜索路径上，它将使用 /usr/local/bin 作为默认方案的 scripts 和 /usr/bin 作为发行版打包的入口点并将两者都放在 $PATH 上。

标记文件

标记文件是否应该位于sys.path中，将特定目录标记为 Python 特定包管理器不允许写入？这将有助于解决此 PEP 解决的第二个问题（不覆盖删除发行版拥有的文件），但不能解决第一个问题（不兼容的安装）。/usr/lib/python3.x/site-packages中的目录特定标记不会阻止安装到/usr/local/lib/python3.x/site-packages或~/.local/lib/python3.x/site-packages中，这两者都位于sys.path中，用于/usr/bin/python3。换句话说，标记文件不应被解释为标记单个目录为外部管理（即使它碰巧位于sys.path上的目录中）；它将整个Python 安装标记为外部管理。

上述内容的另一种变体：标记文件是否应该位于sys.path中，如果它可以在sys.path中的任何目录中找到，则它将安装标记为外部管理？这种方法的一个明显的优势是它会自动在虚拟环境中禁用自身。不幸的是，这在具有--system-site-packages的虚拟环境中具有错误的行为，其中系统范围内的sys.path是可见的，但允许进行包安装。（如果保留免除虚拟环境的规则，它可以工作，但这似乎与当前方案相比没有任何优势。）

标记是否应该只是sysconfig方案的新属性？这在概念上有一些简洁性，除了很难覆盖之外。我们希望使容器镜像、包构建环境等能够轻松抑制标记文件。可以删除的文件很容易；sysconfig中的代码更难修改。

文件是否应该位于/etc中？不，因为同样，它指的是特定的 Python 安装。安装自己 Python 的用户可能希望在该解释器的全局上下文中安装包。

配置设置是否应该位于pip.conf或distutils.cfg中？除了上面关于标记安装的反对意见之外，此机制对这两个工具都不是特有的。（pip 也实现一个配置标志以防止用户在任何 Python 安装中执行意外的非虚拟环境安装似乎是合理的，但这超出了此 PEP 的范围。）

文件是否应该为 TOML 格式？TOML 正在越来越受欢迎用于打包（例如，参见PEP 517），但尚未在标准库中实现。严格来说，这不是一个障碍——发行版只需要写入文件，而无需读取它，因此它们不需要 TOML 库（无论格式如何，文件都可能手动编写），并且打包工具可能已经有一个 TOML 阅读器。但是，INI 格式目前用于各种其他形式的打包元数据（例如，pydistutils.cfg和setup.cfg），满足我们的需求，并且可以由标准库解析，并且 pip 维护者表示希望避免目前使用 TOML。

文件是否应该为email.message样式？虽然此格式也用于打包元数据（例如 sdist 和 wheel 元数据）并且也可以由标准库解析，但它处理多行条目不太清楚，而这是我们的主要用例。

标记文件是否应该为可执行的 Python 代码，用于评估是否允许安装？除了上面关于将文件放在sys.path中的担忧之外，我们还担心使其可执行会使用过强的 API 并可能使行为更难以理解。（请注意，bpo-43976的get_default_scheme钩子实际上是可执行的，但该代码需要在解释器构建时提供；它并非旨在在构建后提供。）

在覆盖标记时，是否应禁止 Python 特定包管理器覆盖由外部包管理器安装的包（即，安装相同名称的模块）？这将最大程度地降低破坏系统软件的风险，但目前尚不清楚这是否值得付出额外的用户体验复杂性。有合理的用例用于覆盖系统包，并且额外的命令行选项以允许它会更令人困惑。同时，不传递该选项不会消除破坏系统软件的风险，系统软件可能依赖于try: import xyz失败、找到有限的入口点等。传达这种区别似乎很困难。我们认为 Python 特定包管理器在覆盖包时打印警告是一个好主意，但我们认为默认情况下禁用它不值得。

为什么不使用PEP 376中的INSTALLER文件来确定谁安装了包以及是否可以将其删除？首先，它特定于特定包（位于包的dist-info目录中），因此，与上面的一些替代方案一样，它不提供有关整个环境以及是否允许包安装的信息。PEP 627还更新了PEP 376以防止以编程方式使用INSTALLER，指定该文件“仅用于信息目的。 […]我们的目标是支持互操作工具，并且根据哪个工具恰好安装了包来采取任何行动与该目标背道而驰。”最后，正如PEP 627设想的那样，有一个工具知道如何处理另一个工具安装的包的合理用例；例如，conda可以安全地删除由pip安装到 Conda 环境中的包。

为什么规范没有提供在虚拟环境中禁用包安装的方法？我们看不到特别强的用例（至少与此 PEP 的目的无关）。如果您需要它，在该环境中pip uninstall pip就足够简单了，这至少会阻止对环境的无意更改（并且此规范没有规定禁用有意更改，因为毕竟标记文件很容易删除）。

系统 Python

发行版软件是否应该只使用发行版site-packages目录在sys.path上，并忽略本地系统管理员的site-packages以及用户特定的site-packages？这是一个有价值的想法，并且它的各种版本在一段时间内以“系统 Python”或“平台 Python”（以及用于最终用户编写 Python 或安装与系统分开的 Python 软件的单独“用户 Python”）的名义流传。但是，这是一个更复杂的变化。首先，这将是一个向后不兼容的更改。如动机部分所述，有有效的用例用于运行使用其sys.path上本地安装的 Python 库的发行版安装的 Python 应用程序，例如 Sphinx 或 Ansible。完全切换到忽略本地包将破坏这些用例，并且发行版必须逐案分析应用程序是否应该查看本地安装的库。

此外，Fedora 尝试了此更改并将其恢复，具有讽刺意味的是，他们发现其更改的实现破坏了其包管理器。鉴于这种经验，在发行版能够可靠地实现这种方法之前，显然需要解决一些细节，并且建议使用 PEP 还为时尚早。

本 PEP 旨在成为一个完整且独立的变更，与发行版是否选择“系统 Python”或类似提案无关。它与发行版将来实现“系统 Python”并不冲突，即使这两个提案都解决了同一类问题，在实现本 PEP 之后，仍然有理由支持实现类似“系统 Python”的东西。 同时，本 PEP 特别尝试进行更具针对性和最小的更改，以便那些不期望采用“系统 Python”（或不期望立即实现它）的发行版也能实现它。本 PEP 中的更改具有自身优点，而不是某个未来提案的中间步骤。本 PEP 降低了（但没有消除）破坏系统软件的风险，同时最大程度地减少了（但没有完全避免）破坏性更改，因此，与完整的“系统 Python”方案相比，它应该更容易实现，而“系统 Python”方案存在上述缺点。

我们预计本 PEP 中的指导——用户应尽可能使用虚拟环境，并且发行版应为发行版管理的模块和本地管理的模块提供单独的 sys.path 目录——将使未来的进一步实验更容易。这些实验可能包括：分发完全独立的“系统”和“用户”Python 解释器；在发行版拥有的虚拟环境或 PYTHONHOME 中运行系统软件（但提供单个解释器）；或修改某些软件（例如发行版的包管理器）的入口点以使用仅看到发行版管理目录的 sys.path。但是，这些想法本身不在本 PEP 的范围之内。