为什么我写了PEP 832——虚拟环境发现

# 为什么我要写 PEP 832 —— 虚拟环境发现 来源：https://snarky.ca/why-i-wrote-pep-832-virtual-environment-discovery/ 在我决定如何处理PEP 832 (https://peps.python.org/pep-0832/)，并在征求大家的意见后（https://discuss.python.org/t/pep-832-virtual-environment-discovery/106998/117），我想写写我为什么还要费心做这些事。 我将从 VS Code 及其Python 扩展 (https://marketplace.visualstudio.com/items?itemName=ms-python.python) 的角度来谈，但你可以轻松地将"VS Code"替换为你喜欢的编辑器，甚至替换为"AI 智能体"，这并不会改变问题本身：对于 VS Code 这样的工具来说，并不容易知道你使用的是哪种工作流（工具），从而知道你把（虚拟）环境放在哪里（我将用"环境"来代指虚拟环境、conda 环境等）。知道环境在哪里很重要，这样才能知道如何运行你的代码（因为环境中有你可以使用的 Python 解释器）、分析你的依赖（以便 linting、自动补全等正常工作）。因此，有一种方法可以向 VS Code 传达在哪里找到环境是很重要的。 ## 问题 ## 首次打开一个项目 当你在 VS Code 中首次打开一个项目时，你可能刚刚执行了`git checkout`，所以什么都没有设置好。VS Code 如何知道你喜欢用什么工作流工具来创建环境呢？你喜欢 Hatch？Poetry？uv？无偏好？还是某个你自用的自定义解决方案（my-tool）？VS Code 也许可以基于`pyproject.toml`中的某个`tool`表来猜测，但这需要有一个已知工具的列表来查找。而且，虽然我知道有些人会说"直接假设是 uv"，但我干这行够久了，知道并不是每个人都用那个工具，而且它也不能保证永远是首选工具（我记得 pipenv 曾被所有人推荐的时候）。目前没有办法知道一个项目希望使用什么工具。同样，如果项目没有明确偏好，而你有个人的偏好，VS Code 也无法知道。VS Code 可以让你在设置中或者项目的`.vscode/settings.json`中指定这样的偏好，但这将是 VS Code 特定的，并且只适用于硬编码支持的工作流工具（抱歉，my-tool 就不行了）。 如果你先执行了`git checkout`，然后运行你的工作流工具来创建环境，接着在 VS Code 中打开项目呢？如果 VS Code 能够自己找到环境，可能会有一个额外的提示说明使用了哪个工具，但这假设 VS Code 知道去那个硬编码的工具列表中的哪个位置寻找环境。这同样有这个问题：需要 VS Code 知道各种工具把环境放在哪里，并且将环境与项目关联起来。而这通常是一个实现细节，因此容易意外变化。 ## 找到所有环境 与找到环境相关的是，你如何知道哪些环境是为这个项目准备的？有些工具将环境保存在项目文件的本地，但有些则保存在全局位置。当发生这种情况时，你需要特定的知识来将环境映射回项目，或者希望工具有一个 CLI 调用，能以不变的方式返回环境列表。 还有一个额外的复杂性：有些工作流工具从不将环境绑定到一个项目上。像 virtualenvwrapper 和 conda 这样的工具允许你命名环境，以便它们可以在多个项目间共享。但这意味着 VS Code 无法知道该使用哪个环境，除非它去询问。而当有人有 700 个甚至更多的环境时（这个数字来自实际经验，并非夸张），就很难知道该推荐哪些环境。 ## 可能的解决方案 让我们从已经拥有一个环境开始，反向推断使用了什么工作流工具。 最简单的情况是，项目的`.venv`目录中有一个虚拟环境。它很容易被发现，因此可以快速使用。但这并不能帮助你修改环境，因为不知道使用了什么工作流工具，以及该工具是否对环境的任何更改有要求，但至少你可以运行代码并分析环境。 对于那些环境保存在项目外部或者有多个环境的情况，可以通过一个记录这些细节的文件来解决。目前我提议使用一个`.python-envs`文件，它是一个用换行符分隔的环境路径列表，最后一个是默认使用的路径（如果用户不想选择的话，顺便说一句，当前 PEP 中的内容是过时的）。 要让一个项目知道应该使用什么工作流工具，目前建议在`pyproject.toml`中通过一个`[workflow]`表来实现。这个表将指定如何以服务器模式启动一个工作流工具，该模式实现了*工作流服务器协议*（WSP，对于语法定义中的空白有不错的含义）。这将允许工具通过 JSON-RPC 在 stdin/stdout 上与 VS Code 通信，告知有哪些环境、创建环境等。VS Code 将提供一种方式来指定当项目没有偏好时的回退工具，但目前并没有考虑如何标准化指定回退工具的方法。 我过去曾提出一个替代方案 (https://github.com/brettcannon/python-launcher/discussions/168)：为 CLI 工具制定某种命名约定，然后它们返回必要的详细信息。这仍然可以使用 WSP 或者制定一个工具实现的 CLI 标准，但这将有助于解决不知道使用哪种回退工具的问题。 ## 我为什么关心这些 VS Code 的使用者涵盖了各种经验水平：从首次编程的初学者到拥有数十年经验的高级程序员。不同经验水平的一个共同点是没有人喜欢设置东西。另一个共同点是没有人喜欢处理环境。因此，我正在努力找到一个大家能同意的解决方案，让入门尽可能简单，并尽可能隐藏环境细节。而且，我希望能以一种非 VS Code 特定的方式做到这一点，如果没必要的话。 除此之外，人们通常不想离开 VS Code 去做任何工作流相关的事情。这使得 VS Code 成为工作流工具的使用者，而不是对等体。因此，VS Code 将工作流工具用作中间件，而通常它们并不是为此设计的。没有工具间的通信标准，最终只能像Hatch 扩展 (https://marketplace.visualstudio.com/items?itemName=PyPA.hatch) 那样提供定制支持，该扩展使用了Python 环境扩展 (https://marketplace.visualstudio.com/items?itemName=ms-python.vscode-python-envs) 的公共 API，这意味着它不容易扩展到帮助其他工具。对于 VS Code 用户来说，这个扩展存在很好，但其他编辑器无法受益。而且，维护扩展需要精力，这本可以用于开发一个适用于任何编辑器的通用解决方案。