Python 构建系统和 Gentoo 的未来_python 3.12 distutils

任何关注我 Twitter 的人都可能看到我抱怨 Python 构建系统经常发生的事情。最近的变化感觉 Python 打包生态系统周围的人们一直非常专注于构建一个新的基础设施，专注于 Python 特定的包管理，如 pip 和 flit。不幸的是，在此过程中似乎很少关注分发打包程序或向后兼容性。

在这篇文章中，我想讨论 Python 打包更改将如何影响 Gentoo，以及我建议的处理它们的计划。我特别想关注三个重要的变化：

1. Python 上游弃用该distutils模块（和构建系统），并计划在 Python 3.12 中将其删除。
2. 基于PEP 517的构建系统的整体兴起以及 setuptools 完全放弃 UI 的潜力。
3. Setuptools 上游弃用该setup.py install命令，并可能在未来将其删除。

distutils 弃用

多年来，distutils stdlib 模块已被用于setup.py为 Python 包构建脚本。除了为包提供构建系统 CLI 的基线功能之外，它还提供了轻松扩展构建系统的能力。这导致setup.py作为一些包的一部分的高度定制的脚本以及基于 distutils 的第三方构建系统的增长，最显着的是setuptools。

这最终导致 distutils 本身被弃用（参见：PEP 632）。Python 3.10 已经警告了 distutils 的弃用，目前的计划是在 Python 3.12 中将其删除。在此之前，开发已转移到专用的pypa/distutils存储库，并且其副本捆绑在 setuptools 中。

默认情况下，setuptools 仍然使用 stdlib distutils。然而，一些包已经切换到捆绑副本，上游计划在未来默认使用它（参见：从 Distutils 移植）。

在这一点上，我认为 Gentoo 没有明确需要在这里采取行动。然而，避免使用 distutils 作为 Gentoo 项目的构建系统似乎是合理的。由于 distutils 的 setuptools 副本与包含在 CPython（和 PyPy）中的副本不同，并且目前它没有携带完整的历史 Gentoo 补丁集，因此测试与它的包兼容性可能是有意义的。

可以使用以下环境变量强制使用捆绑的 distutils 副本：

SETUPTOOLS_USE_DISTUTILS=local
1

这可以在特定的 ebuild 中设置，也可以在make.conf全局强制中设置。但是，请注意，如果没有版本凹凸（修订凹凸不够），则无法就地更改变量。这是因为切换到本地变体涉及将 .egg-info 文件替换为 PMS 不支持且 Portage 处理不当的目录。

假设上游迟早会更改默认值（因此对我们造成破坏），我认为最干净的方法是：

1. 执行一些初始测试（通过 tinderboxes）。
2. 通过 eclass启用SETUPTOOLS_USE_DISTUTILS=local时DISTUTILS_USE_SETUPTOOLS!=no（变量名称相似性是巧合）。
3. 弃用DISTUTILS_USE_SETUPTOOLS=no，要求维护者在将软件包升级到新版本时进行切换。

该计划的目的是有很好的机会测试新的默认值并在上游强制其到位之前迁移尽可能多的包。在已经使用 setuptools 的包上更改 distutils provider 应该是相对安全的。另一方面，对于使用纯 distutils 的包，它应该通过版本颠簸发生，以避免前面提到的文件目录冲突。同时，DISTUTILS_USE_SETUPTOOLS值的更改将是必要的，因为现在需要 setuptools 依赖项来提供 distutils 覆盖。

我已经要求进行初始 tinderbox 测试。如果一切顺利，我们决定按照计划执行，我稍后会提供详细说明。 请不要更新 ebuild。

PEP 517 的兴起

PEP 517（以及更多相关的 PEP）定义了用于安装 Python 包的新基础架构。长话短说，他们定义了一个一致的 API，可以由任意构建系统公开，以支持从任何包管理器使用它。听起来很棒，对吧？嗯，我没那么热情。

在我开始讨论我的原因之前，让我们简要总结一下构建包在 PEP 517 世界中应该如何工作。每个项目至少提供一个最小pyproject.toml文件，指定提供构建系统的包和提供其入口点的模块的路径。您阅读该文件，安装必要的软件包，然后调用适当的入口点以获取轮子。然后你安装轮子。大致。

首先，TOML。这是我已经重复了很长时间的事情，所以我会快速回顾一下。我喜欢 TOML，我认为这是标记的合理选择。但是，如果 stdlib 中没有 TOML 解析器（并且在提供解析器方面没有任何进展），这意味着每个构建系统现在都依赖于tomli，并且涉及循环依赖。几个月前，每个构建系统都依赖于，toml但那个包变得无人维护。这让你感到自信吗？

其次，定制。在这一点上，我们对 distutils/setuptools 行为进行了大量定制——构建路径、安装路径、工具链。可以理解的是，PEP 517 使用了黑盒方法并且没有尝试全部完成。不幸的是，到目前为止，构建在 PEP 517 之上的构建系统似乎专注于提供一体化的包管理器，而不是具有自定义支持的良好构建工具。

第三，轮子。PEP 517 几乎迫使每个人都使用wheel 包格式，完全忽略了这样一个事实，即它既不是最简单的解决方案，也不适合发行版。我们缺少的是一个简单的“将所有文件放入一个目录”的入口点。如果“将所有内容打包成一个 zip，然后使用下一个工具解压缩它们”，我们会得到什么。当然，这对大多数包裹来说没什么大不了的，但我只是讨厌浪费电力和用户时间来压缩某些东西的想法，这样它就可以在之后解压缩。

PEP 660通过提供“可编辑安装”支持来避免这种情况。不幸的是，它是如此黯淡，几乎没有指定任何内容。在实践中，PEP 660 可编辑安装通常是一个 .dist-info + .pth 文件，将源目录添加到sys.path其中 - 这意味着实际上没有安装文件，并且它不会让我们更容易找到正确的文件进行安装. 换句话说，它完全没有用。

我花了大量时间寻找一个好的解决方案，但到目前为止还没有找到。回到那天，我编写了pyproject2setuppy作为一个权宜之计，通过 setuptools 安装基于 PEP 517 的包，而不必打包新的构建系统（包括它们的NIH依赖项），并找出如何使它们在我们的包框架内正常工作. 直到今天，我仍然没有看到更好的解决方案。

鉴于 setuptools 似乎旨在完全删除 CLI 并且不再维护 distutils，我怀疑在某些时候我们将不可避免地不得不以一种或另一种方式咬紧牙关。然而，我暂时不打算做任何改变——只要setup.py install继续工作，就是这样。当这不再可行时，我们可以再次研究我们的选择。

setup.py 安装弃用

最后，最后一个事件让其他一切都变得清晰：上游的 setuptools 已弃用install命令。虽然通常我会说“它不会很快被删除”，但不加区分的use_2to3 删除表明情况并非如此。

简单回顾一下：setuptoolsuse_2to3在被弃用一段时间后移除了支持，总结为“项目应该移植到统一的代码库或固定到旧版本的 Setuptools”。当然，nose是一个自 2016 年以来没有看到过一次提交（或接受的用户补丁）的项目，它会突然发布一个版本来解决这个问题。最后，所有的破损都倾倒在分发包装商身上。

该install命令去除是比这更大的交易。这不仅仅是一些旧包被破坏，而是整个工作流程。一段时间以来，我一直在考虑将 Gentoo 切换到不同的工作流程，但没有太大影响。即使我们硬着头皮使用 PEP 517，还有另一个主要问题：有些项目会覆盖install命令。

我的意思是，如果我们不加选择地切换到没有install命令的安装，一些包实际上会被静默破坏——例如，它们会停止安装一些文件。最大的问题是找到这样的包并非易事。我所知道的一种叫做 Portage。

在这一点上，我认为努力寻找setup.py install. 当我们到达时，我们可以过那座桥。在那之前，这似乎是一项不必要的工作，具有相当大的破损潜力。

最后，目前还不清楚什么是最好的解决方案。我们可能会继续将 flit 和诗歌转换为 setuptools，以避免必须维护对多个构建过程的支持。我们可能会在现有的 PEP 517 工具之上进行 hack，或者构建某些东西或拥有它。如果我找不到其他解决方案，我很可能会尝试修补构建系统以复制文件而不是压缩它们，或者至少禁用压缩。

概括

Python 生态系统在不断变化，它的包装方面也不例外。最初的 distutils 构建系统最终演变为 setuptools，现在正被它所包含。Setuptools 似乎正在朝着成为另一个 PEP 517 构建后端和不加选择地删除功能的方向发展。

不幸的是，这一切都发生了，而没有太多关注向后兼容性或功能奇偶校验。Python 开发人员专注于构建他们自己的打包基础设施，并没有兴趣为分发打包人员提供单一的良好工作流程。鉴于他们中的许多人依赖我们的工作来构建他们用来工作的环境，这真的很不幸。

在这一点上，我们的直接目标是为 distutils 删除做好准备，并且 setuptools 切换到捆绑的 distutils 副本。这个切换对于 Gentoo 用户来说具有真正的破坏潜力（因为 egg-info 文件/目录冲突），我们需要提前优雅地处理迁移。其他问题。值得注意的是setup.py install，未来也需要处理移除问题，但现在所取得的成果并不能证明这一努力是值得的。

更新 (2021-11-10)：数据文件支持

在写这篇文章时，我错过了 PEP 517 构建的一个重要限制。Distutils 和 setuptools 都有一个data_files特性，可以用来将任意文件安装到系统中——或者安装到sys.prefix(ie /usr) 的子目录中，或者通过绝对路径。这通常用于安装包的数据文件，但也用于安装联机帮助页、.desktop 文件等。

到目前为止，wheel 规范根本不支持在少数 Python 特定目录之外安装文件。Setuptools/wheel/pip 似乎将它们包含在轮子中，但它超出了规范，因此可能会遇到可移植性问题。

不幸的是，似乎没有兴趣真正解决这个问题。除非我弄错了，flit 和诗歌都不支持在标准 Python 目录之外安装文件。

Ref: https://blogs.gentoo.org/mgorny/2021/11/07/the-future-of-python-build-systems-and-gentoo/