提供者

提供者是向与 Python 打包以及因此与 Python 软件包安装程序进行交互的服务或软件工具提供服务的方（组织、个人、社区等）。考虑两种不同的提供者类型

开发者

开发者是编写和使用 Python 软件包安装程序和 Python 软件包的团队、个人或社区。考虑三种不同的开发者类型

升级者和软件包基础设施提供者

软件包升级者和 CI/CD 中的软件包基础设施（如 Dependabot、PyUP 等）目前支持一些安装程序。它们通过直接解析和编辑特定于安装程序的依赖项文件（如 requirements.txt 或 poetry.lock）来工作，其中包含相关软件包信息（如升级、降级或新哈希值）。与平台和 IDE 提供者类似，大多数这些提供者不想支持 N 种不同的 Python 软件包安装程序，因为这将需要支持 N 种不同的文件类型。

目前，这些服务/机器人必须分别实现对每个软件包安装程序的支持。不可避免地，最流行的安装程序首先得到支持，而不太流行的工具往往得不到支持。通过实现此规范，这些服务/机器人可以支持任何（符合规范的）安装程序，允许用户选择他们想要的工具。这将允许该领域有更多创新，因为平台和 IDE 不再被迫过早地选择“获胜者”。

开源社区

指定安装程序要求并采用此 PEP 将减少 Python 软件包安装程序与人们工作流程之间的摩擦。因此，它将减少 Python 软件包安装程序与第三方基础设施/技术（如 PaaS 或 IDE）之间的摩擦。总的来说，它将允许更轻松地开发、部署和维护 Python 项目，因为 Python 软件包安装变得更简单，并且更具互操作性。

指定要求和为安装程序创建接口还可以加快安装程序领域的创新速度。这将允许安装程序进行实验并添加独特的功能，而无需要求生态系统中的其他部分也这样做。无论添加的功能和写入依赖项的格式如何，新安装程序的支持变得更容易，并且可能性更大，同时减少了开发人员所需的时间和资源。

[install-system]

install-system 表用于存储与安装系统相关的數據和信息。此表需要多个键：requires 和 install-backend。 requires 键保存执行安装后端的最低要求，这些要求将由通用安装器安装。 install-backend 键保存安装后端入口点的名称。这将允许通用安装器安装执行安装后端本身所需的条件（而不是安装后端本身将安装的条件），以及调用安装后端。

如果缺少或为空任何必需的键，则通用安装器应引发错误。

与该接口交互的所有软件包名称假定遵循 PEP 508 的“Python 软件包的依赖项规范”格式。

示例 install-system 表

#pyproject.toml
[install-system]
#Eg : pipenv
requires = ["pipenv"]
install-backend = "pipenv.api:main"

[tool.poetry.dev-dependencies]
dependencies = "dev"

[tool.poetry.deploy]
dependencies = "deploy"

安装程序接口

安装器接口包含强制和可选钩子。符合标准的安装后端必须实现强制钩子，并且可以实现可选钩子。通用安装器可以自行实现任何安装后端钩子，以充当通用安装器和安装后端，但这并非必需。

所有钩子都接受 **kwargs 任意参数，这些参数是安装后端可能需要的，但尚未指定，允许向后兼容。如果将意外参数传递给安装后端，它应该忽略它们。

以下信息类似于 PEP 517 中相应部分的信息。可以将关键字参数传递给钩子，因此实现它们的安装后端应注意确保其签名与以上参数的顺序和名称匹配。

所有钩子都可以将任意信息文本打印到 stdout 和 stderr。它们不得从 stdin 读取，并且通用安装器可以在调用钩子之前关闭 stdin。

通用安装器可以捕获来自后端的 stdout 和/或 stderr。如果后端检测到输出流不是终端/控制台（例如，不是 sys.stdout.isatty()），它应确保写入该流的任何输出都是 UTF-8 编码的。如果捕获的输出不是有效的 UTF-8，则通用安装器不得失败，但它可能无法保留所有信息（例如，它可以使用 Python 中的替换错误处理程序进行解码）。如果输出流是终端，则安装后端负责准确地呈现其输出，就像在终端中运行的任何程序一样。

如果钩子引发异常或导致进程终止，则表示错误。

强制钩子

def invoke_install(
    path: Union[str, bytes, PathLike[str]],
    *,
    dependency_group: str = None,
    **kwargs
) -> int:
    ...

可选钩子

def invoke_uninstall(
    path: Union[str, bytes, PathLike[str]],
    *,
    dependency_group: str = None,
    **kwargs
) -> int:
    ...

def get_dependencies_to_install(
    path: Union[str, bytes, PathLike[str]],
    *,
    dependency_group: str = None,
    **kwargs
) -> Sequence[str]:
    ...

def get_dependency_groups(
    path: Union[str, bytes, PathLike[str]],
    **kwargs
) -> AbstractSet[str]:
    ...

def update_dependencies(
    path: Union[str, bytes, PathLike[str]],
    dependency_specifiers: Iterable[str],
    *,
    dependency_group=None,
    **kwargs
) -> int:
    ...

标准化的锁文件

一个标准化的锁定文件将解决指定安装程序要求将解决的许多相同问题。例如，它将允许 PaaS/IaaS 只支持一个安装程序，该安装程序可以读取标准化的锁定文件，而不管创建它的安装程序是什么。标准化锁定文件的问题是 Python 包安装程序之间的需求差异，以及通过锁定文件创建可重复环境的基本问题（主要优点之一）。

安装程序之间依赖项文件中存储的需求和信息差异很大，并且取决于安装程序的功能。例如，Poetry 这样的 Python 包安装程序需要所有 Python 版本和平台的信息，并计算相应的哈希值，而 pip 则不会。此外，pip 无法保证重建相同的环境（安装完全相同的依赖项），因为它超出了其功能范围。这使得标准化的锁定文件更难实现，并且似乎更适合将锁定文件设置为特定于工具的。

让安装程序后端支持创建虚拟环境

由于安装后端很可能会有关于虚拟环境的概念以及如何安装到虚拟环境中的概念，因此曾短暂地考虑过让它们也支持创建虚拟环境。但最终，它被认为是一个正交的想法。

dependency_group 参数是否应该接受可迭代对象？

这将允许在一个调用中指定不重叠的依赖组，例如“docs”和“test”组，它们具有独立的依赖项，但开发人员可能希望在进行开发时同时安装它们。

安装程序后端是在进程内执行的吗？

如果安装后端在进程内执行，那么它极大地简化了知道为哪个环境/安装到哪个环境的流程，因为可以查询实时 Python 环境以获取相应的信息。

进程外执行允许最大程度地减少被安装到其中的环境与安装后端（以及可能通用安装器）之间潜在冲突的问题。

强制执行从提议接口中获取的结果馈送到其他部分？

例如，来自 get_dependencies_to_install() 和 get_dependency_groups() 的结果可以传递给 invoke_install()。这将防止所提议接口的各个部分之间出现偏差，但它使得更多接口成为必需的，而不是可选的。

对于失败条件，引发异常而不是退出代码

有人建议，API 应该抛出异常，而不是返回退出代码。如果您将此 PEP 视为帮助将当前安装程序转换为安装程序后端，那么依赖退出代码是有意义的。此外，API 没有特定的返回值，因此传递退出代码不会干扰函数的返回值。

将此与在出错时抛出异常进行比较。这可能会提供一种更结构化的错误抛出方法，虽然为了能够捕获错误，需要将异常类型指定为接口的一部分。