摘要

此 PEP 建议，像 pip 这样的包安装程序在 Python 3.13+ 上默认要求使用虚拟环境。

PEP 撤回

在此 PEP 的讨论过程中，很明显，对 pip 用户体验的更改不受 PEP 所提议的控制。此外，还清楚地表明，相当多的用户依赖于能够将由 pip 管理的依赖项与由其他工具管理的依赖项混合使用（最显著的是在使用 Conda 时）。

此外，所提议变更的好处可以通过 PEP 668（在撰写本文时已接受并实现）来实现相当一部分。它允许 Python 解释器的再分发者控制用户是否应该被要求使用虚拟环境、向用户展示的消息以及该更改如何为他们的用户进行推广。

由于在此 PEP 中强制使用 pip 的虚拟环境是主要焦点，因此撤回此 PEP 比将其重定向到不同主题更为合适。

未来解决虚拟环境命名约定问题/挑战的 PEP 仍然是合适的，但任何此类工作都应作为一个新的 PEP 来开始，该 PEP 侧重于此类约定的好处，而不是强制执行它。

动机

Python 虚拟环境是 Python 开发工作流的重要组成部分。然而，它们需要额外的努力，因为它们是一个选择加入的功能，并且需要用户要么

• 采取明确的步骤来激活/停用虚拟环境
• 使用 <path-to-venv>/<bin-path>/<executable> 来运行文件

对于新用户来说，当不使用虚拟环境时，事情似乎会正常工作——直到它们不再正常工作。此外，激活虚拟环境在不同平台上使用略有不同的语法和机制。这增加了虚拟环境的入门难度，因为现在需要解释有关其有用性、如何使用以及为何有用的信息和背景，以证明在工作流中添加额外步骤是合理的。

这还会造成出错的范围，因为用户需要记住在运行像 pip 这样的安装程序之前激活虚拟环境，或者配置这些安装程序以出错退出。在某些 Linux 发行版上，忘记这样做可能会导致安装程序修改操作系统拥有的文件（这在某种程度上通过 PEP 668 得到了缓解，前提是发行版选择将其环境标记为相应）。

基本原理

将像 pip 这样的安装程序的默认行为更改为要求激活虚拟环境，将

• 使新用户更容易开始使用 Python（因为有一个一致的体验，并且虚拟环境被理解为是必须使用的东西）
• 通过默认明确标记您没有使用虚拟环境，从而减少所有用户意外安装问题的范围。

将虚拟环境设置在项目目录中，并命名为 .venv，这消除了常见工作流中的一个决策点，并在生态系统中创建了一个清晰的约定。

规范

向后兼容性

此 PEP 与用户在虚拟环境外部使用安装程序的现有工作流不兼容。此类用户将收到错误消息，并且需要要么

• 明确选择在虚拟环境外部运行安装程序，或
• 创建并使用虚拟环境

已经在使用虚拟环境的用户将不受此更改的影响。

工作流工具（在幕后为用户管理虚拟环境）应不受影响，因为它们应该已经在运行安装程序时使用虚拟环境。

安全隐患

此 PEP 不会引入任何新的安全影响。

如何教授此内容

此 PEP 要求新用户在开始使用 Python 包时创建并使用虚拟环境。然而，这是一种最佳实践，正如 Python 打包用户指南中关于“安装 Python 包的基础知识”的部分 所示，该部分在讨论使用 pip 之前解释了虚拟环境是什么以及如何使用。

参考实现

此 PEP 没有参考实现。然而，提议的行为在 pip 中已在很大程度上实现，并且可以通过将 PIP_REQUIRE_VENV 环境变量设置为 1 来激活。（将其设置为未设置则会产生不要求在安装时使用虚拟环境的提议的 opt-in 行为。）

实现说明

def is_virtual_environment():
    return sys.base_prefix != sys.prefix or hasattr(sys, "real_prefix")

被拒绝的想法

未解决的问题

无。

版权

本文档置于公共领域或 CC0-1.0-Universal 许可证下，以更宽松者为准。