LWN: Fedora 2020年Python工作总结！

关注了就能看到更多这么棒的文章哦～

A year of Python in Fedora

By Jake Edge
January 27, 2021
DeepL assisted translation
https://lwn.net/Articles/844203/

Linux 各个发行版的开发人员做了大量的工作来确保各种编程语言的生态系统在这个发行版中是可以正常使用的。这是个人们不太意识到价值的工作，只有在出现问题或有人投诉时才会注意到这个工作的价值。最近 Miro Hrončok 整理了一份 Fedora Python 团队在 2020 年的工作内容回顾。虽然它介绍的内容显然是针对 Fedora 的，但能给大家一窥各个发行版团队内部工作的情况。

发布在 Fedora 的 devel mailing list 的公告文章中，Hrončok 说他的灵感来自于 Miroslav Suchý为 Cool Other Package Repo (Copr) 团队所做的类似工作。那份报告广受好评，所以 Hrončok 也跟着做了这个总结报告。也许这种方式会在其他的 Fedora 团队以及其他发行版中流行起来。

Hrončok 是 Red Hat 的 Python 维护团队的成员，也是 Fedora Python 特别兴趣小组(SIG)的成员。他指出，2020 年在 Python 世界中是特殊的一年，因为 Python 2 系列在 1 月 1 日就走到了生命的终点（尽管 4 月份还发布了 2.7.18 纪念版）。核心开发者们对 Python 2.7 的支持工作已经停止了，但 Red Hat 的维护者仍会在未来一段时间内为 Red Hat Enterprise Linux 开发安全更新。

2020 年发布过两个版本的 Fedora（4 月底的 Fedora 32 和 10 月底的 Fedora 33），10 月初的时候还有新的 Python 3.9 发布。但是 Fedora 32 发布的时候是采用当时最新版本 3.8，Python 3.8 是上一年 10 月发布的。Python 3.8 当时错过了 Fedora 31，"因为 Python 和 Fedora 的发布时间表太对不上了，开发者们不能确保这么早升级还能给出可靠结果"。今后的话，这两者的发行流程经过调整后已经得到改善，所以为 Fedora 33 开发 Python 3.9 的工作早在两者发布之前就开始了。

Python 2 的退役，导致 Python 3.9 中移除了一些兼容 2.7 的特性。因为提前对 Python 3.9 进行了测试，Hrončok 和 Victor Stinner 意识到这些被移除的功能会导致许多软件包无法成功构建。他们成功地劝说 Python 核心开发者将这些移除动作推迟到后续的 Python 3.10，这样使用 Python 的项目可以有更多的时间来适应这个新情况。与此同时，预计于 2021 年 10 月发布的 Python 3.10，Fedora 早在 2020 年就开始在上面工作了，希望在同样是 10 月份发布的 Fedora 35 中能成功应用起来。

可以看到，有很多变动内容需要不断跟踪和测试。在 2020 年还有一个可以看到改进的领域是针对 Python 的持续集成（CI）测试。Fedora 和 RHEL 的 Python CI 测试中支持了更多的体系结构，包括 s390x、pc64le 和 arch64。对 upstream Python 定期进行测试，有助于发现 Python 中的 bug 以及发行版中其他地方的一些问题（可能与 python 无关的问题）。Hrončok 举的例子是 aarch64 的 brk() 中的一个 bug (https://bugzilla.redhat.com/show_bug.cgi?id=1797052)，以及在 ppc64le 上使用 GCC 10 进行构建的问题 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384)。

Fedora 中 Python 包的数量确实让人大开眼界，这门语言显然在发行版中占了很大的比重：

自 Fedora 31 在 2019 年底发布以来，Fedora 中 Python 包的整体数量已经从约 3150 个增长到约 3900 个。它们目前占所有 Fedora 软件包的约 17%。超过 700 个不同的人(通过不同的电子邮件地址来判断，并且去除了明显重复的地址以及机器人) 都在 2020 年对这些软件包进行过 commit 提交。

2020 年出现了一个有趣的功能，就是新的 marshalparser 工具，它可以作为 RPM 构建过程的一部分，以确保编译后的 Python 文件(即.pyc 文件) 每次在从相同的源码构建时，每个 bit 都是相同的。Python marshal serializer 在某些情况下会产生不同的字节码，正如 Bugzilla 的讨论中所描述的那样。所以新的 marshalparser 可以用在需要的地方，将每次生成的字节码固定下来。这对于 reproducible builds 来说是很重要的。

Fedora 在自己的场景中测试了使用 -fno-semantic-interposition GCC flag 的效果，它为 Python 带来了显著的性能提升。这个 flag 通过移除掉默认的 interposition 机制，有效地缩短了在函数库中查找函数的路径，该机制允许使用 LD_PRELOAD 加载的库来覆盖指定函数。这样导致 libpython 无法使用 LD_PRELOAD ，但是减少了对 CPU 的 instruction cache (指令缓存)的压力，在不同的场景中，性能提升可能高达 27%。这项改动是针对 Fedora 32 进行的，现在已经成为 upstream CPython 构建过程的一部分。它已经被移植到 RHEL 8 和 CentOS 中的 Python 旧版本上用了起来。

大多数发行版长期以来一直自己维护着一个 patch，就是将 Python 的 module 都安装到 /usr/lib64 (而不是 /usr/lib)，这个 patch 现在已经进入 CPython mainline。这项贡献来自于 Fedora 和 openSUSE 开发者，这就意味着这些发行版（以及其他发行版，比如 Gentoo 和 Debian），可以不再自己维护这个已经存在了 16 年的 patch。

这些只是 Hrončok 在报告中记录的一部分亮点。他还预测了一下 2021 年将会开展哪些工作：

在接下来的几个月里，我们团队的优先事项（除了不断地将 CVE fix 来 backport 移植到无数个 component 上面去之外）就是 RHEL 8 的 Python 3.9 module，Fedora 35 中的 Python 3.10（还有 Fedora 37 中的 3.11，听起来很遥远，但适合在 2021 年开始），还有更多的 RHEL 9 的工作，最终提出 new Python guidelines 文档，并可能会创建一个新的 spec file generator 来利用 pyproject 宏[https://src.fedoraproject.org/rpms/pyproject-rpm-macros]。我们可能最终会做的事情是尽量减小文件系统内容[https://github.com/hroncok/python-minimization/blob/master/document.md]。

这份报告很好地展示了 Linux 发行版为了将 Python 这样的语言集成到其生态系统中会做哪些工作。让两个大项目很好地结合在一起，这需要很多努力，但 Fedora Python SIG 的目标之一就是 "确保 Fedora 是对 Python 开发者来说最佳的操作系统"。其他发行版可能会不同意这一点，但这说明大家会进行友好竞争，这只会让 Linux 上的 Python 变得更好。这才是对大家都有好处的事情。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～