Python 打包 2023 年回顾

A year ago, I wrote about the sad state of Python packaging. The large number of tools in the space, the emphasis on writing vague standards instead of rallying around the One True Tool, and the complicated venv-based ecosystem instead of a solution similar to node_modules. What has changed in the past year? Has anything improved, is everything the same, or are things worse than they were before?
一年前，我写了一篇关于Python打包的悲惨状态的文章。该领域的大量工具，强调编写模糊的标准而不是围绕一个真正的工具，以及复杂的 venv 基于生态系统而不是类似于 node_modules .在过去的一年里发生了什么变化？有什么改进吗，一切都一样，还是比以前更糟？

The tools 工具

The original post listed a bunch of packaging tools, calling fourteen tools at least twelve too many. My idea with that was that most people would be happy with one tool that does everything, but the scientific-Python folks might have special requirements that would work best as a second tool.
原帖列出了一堆打包工具，称十四个工具至少十二个太多了。我的想法是，大多数人会对一个可以做所有事情的工具感到满意，但科学 Python 的人可能会有特殊要求，最适合作为第二个工具。

Out of the tools named in last year’s post, all of them still seem to be maintained. Except for Flit (zero new commits in the past 30 days) and virtualenv (only automated and semi-automated version bumps), the tools have recent commits, pull requests, and issues.
在去年的帖子中提到的工具中，所有这些工具似乎都得到了维护。除了 Flit（过去 30 天内没有新提交）和 virtualenv（只有自动和半自动版本颠簸）之外，这些工具都有最近的提交、拉取请求和问题。

All of those tools are still in use. Françoise Conil analysed all PyPI packages and checked their PEP 517 build backends: setuptools is the most popular (at 50k packages), Poetry is second at 41k, Hatchling is third at 8.1k. Other tools to cross 500 users include Flit (4.4k), PDM (1.3k), Maturin (1.3k, build backend for Rust-based packages).
所有这些工具仍在使用中。Françoise Conil 分析了所有 PyPI 软件包并检查了他们的 PEP 517 构建后端：setuptools 是最受欢迎的（50k 包），Poetry 以 41k 排名第二，Hatchling 以 8.1k 排名第三。其他跨 500 个用户的工具包括 Flit （4.4k）、PDM （1.3k）、Maturin （1.3k，为基于 Rust 的软件包构建后端）。

There are some new tools, of course. Those that crossed my radar are Posy and Rye. Posy is a project of Nathaniel J. Smith (of trio fame), Rye is a project of Armin Ronacher (of Flask fame). The vision for both of them is to manage Python interpreters and projects, but not have a custom build backend (instead using something like hatchling). Posy is built on top of PyBI (a format for distributing binaries of Python interpreters, proposed by Smith in draft PEP 711), Rye uses Gregory Szorc’s pre-built Pythons. Rye seems to be fairly complete and usable, Posy is right now a PoC of the PyBI format, and only offers a REPL with pre-installed packages.
当然，也有一些新工具。那些越过我雷达的是 Posy 和 Rye。Posy 是 Nathaniel J. Smith（三重奏成名）的项目，Rye 是 Armin Ronacher（Flask 成名）的项目。他们俩的愿景是管理 Python 解释器和项目，但没有自定义构建后端（而是使用类似 hatchling 的东西）。Posy 建立在 PyBI（一种用于分发 Python 解释器二进制文件的格式，由 Smith 在 PEP 711 草案中提出）之上，Rye 使用 Gregory Szorc 的预构建 Python。Rye 似乎相当完整且可用，Posy 现在是 PyBI 格式的 PoC，并且只提供带有预安装软件包的 REPL。

Both Posy and Rye are written in Rust. On the one hand, it makes sense that the part that manages Python interpreters is not written in Python, because that would require a separate Python, not managed by Posy/Rye, to run those tools. But Rye also has its own pyproject.toml parser in Rust, and many of its commands are implemented mostly or largely using Rust (sometimes also calling one-off Python scripts; although the main tasks of creating venvs, installing packages, and working with lockfiles are handed off to venv, pip, and pip-tools respectively).
Posy 和 Rye 都是用 Rust 编写的。一方面，管理 Python 解释器的部分不是用 Python 编写的，这是有道理的，因为这需要一个单独的 Python，而不是由 Posy/Rye 管理，来运行这些工具。但 Rye 在 Rust 中也有自己的 pyproject.toml 解析器，它的许多命令主要或大部分是使用 Rust 实现的（有时也会调用一次性的 Python 脚本;尽管创建 venvs、安装软件包和处理锁文件的主要任务分别交给 venv 了 、 pip 和 pip-tools ）。

Speaking of Rust and Python, there’s been another project in that vein that has grown a lot (and gathered a lot of funding) in the past year. That project is Ruff, which is a linter and code formatter. Ruff formats Python code, and is written in Rust. This means it’s 10–100× faster than existing tools written in Python (according to Ruff’s own benchmarks). Fast is good, I guess, but what does this say about Python? Is the fact that package tools (which aren’t rocket science, maybe except for fast dependency solvers, and which often need access to Python internals to do their job) and code formatters (which require a deep understanding of Python syntax, and parsing Python sources to ASTs, something easy by the ast Python module) are written in another language? Does this trend make Python a toy language (as it is also often considered a glue language for NumPy and friends)? Also, why should contributing to a tool important to many Python developers require learning Rust?
说到 Rust 和 Python，在过去的一年里，还有另一个项目发展了很多（并获得了大量资金）。这个项目是 Ruff，它是一个 linter 和代码格式化程序。Ruff 格式化 Python 代码，并用 Rust 编写。这意味着它比用 Python 编写的现有工具快 10-100×（根据 Ruff 自己的基准测试）。我想，快速是好事，但这对 Python 有什么影响呢？包工具（可能不是火箭科学，也许除了快速依赖求解器，并且通常需要访问 Python 内部才能完成其工作）和代码格式化程序（需要深入了解 Python 语法，并将 Python 源代码解析为 ast AST，Python 模块很容易）是用另一种语言编写的吗？这种趋势是否使 Python 成为一种玩具语言（因为它也经常被认为是 NumPy 和朋友的胶水语言）？另外，为什么为一个对许多 Python 开发人员很重要的工具做出贡献需要学习 Rust？

The standards 标准

Last time we looked at packaging standards, we focused on PEP 582. It proposed the introduction of __pypackages__, which would be a place for third-party packages to be installed to locally, on a per-project basis, without involving virtual environments, similarly to what node_modules is for node. The PEP was ultimately rejected in March 2023. The PEP wasn’t perfect, and some of its choices were questionable or insufficient (such as not recursively searching for __pypackages__ in parent directories, or focusing on simple use-cases only). No new standards for something in that vein (with a better design) were proposed to this day.
上次我们研究包装标准时，我们关注的是 PEP 582。它建议引入 ，这将是一个将第三方软件包安装到本地的地方，基于每个项目，而不涉及虚拟环境 __pypackages__ ，类似于 node_modules node。PEP 最终于 2023 年 3 月被拒绝。PEP 并不完美，它的一些选择是有问题的或不充分的（例如不递归地在父目录中搜索 __pypackages__ ，或者只关注简单的用例）。直到今天，还没有为这种东西（具有更好的设计）提出新的标准。

Another contentious topic is lock files. Lock files for packaging systems are useful for reproducible dependency installations. The lock file records all installed packages (i.e. includes transitive dependencies) and their versions. Lock files often include checksums (like sha512) of the installed packages, and they often support telling apart packages installed via different groups of dependencies (runtime, buildtime, optional, development, etc.).
另一个有争议的话题是锁定文件。打包系统的锁定文件对于可重现的依赖项安装非常有用。锁定文件记录了所有已安装的软件包（即包括传递依赖项）及其版本。锁定文件通常包含已安装软件包的校验和（如 sha512），并且它们通常支持区分通过不同依赖项组（运行时、构建时、可选、开发等）安装的软件包。

The classic way of achieving this goal are requirements.txt files. They are specific to pip, and they only contain a list of packages, versions, and possibly checksums. Those files can be generated by pip freeze, or the third-party pip-compile from pip-tools. pip freeze is very basic, pip-compile can’t handle different groups of dependencies other than making multiple requirements.in files, compiling them, and hoping there are no conflicts.
实现此目标的经典方法是 requirements.txt 文件。它们特定于 pip，并且仅包含包、版本和可能的校验和的列表。这些文件可以由 pip freeze 生成，也可以 pip-compile 由 第三方生成 pip-tools 。 pip freeze 非常基础， pip-compile 除了制作多个 requirements.in 文件、编译它们并希望没有冲突之外，无法处理不同的依赖项组。

Pipenv, Poetry, and PDM have their own lockfile implementations, incompatible with one another. Rye piggybacks on top of pip-tools. Hatch doesn’t have anything in core; they’re waiting for a standard implementation (there are some plugins though). PEP 665 was rejected in January 2022. Its author, Brett Cannon, is working on a PoC of something that might become a standard (named mousebender).
Pipenv、Poetry 和 PDM 有自己的锁文件实现，彼此不兼容。黑麦捎带在 pip-tools .Hatch 的核心没有任何内容;他们正在等待标准实现（虽然有一些插件）。PEP 665 于 2022 年 1 月被拒绝。它的作者布雷特·坎农（Brett Cannon）正在研究一种可能成为标准的PoC（名为mousebender）。

This is the danger of the working model adopted by the Python packaging world. Even for something as simple as lock files, there are at least four incompatible standards. An attempt at a specification was rejected due to “lukewarm reception”, even though there exist at least four implementations which are achieving roughly the same goals, and other ecosystems also went through this before.
这就是 Python 打包世界采用的工作模型的危险所在。即使对于像锁定文件这样简单的东西，也至少有四个不兼容的标准。由于“反应冷淡”，规范的尝试被拒绝了，尽管至少有四个实现实现了大致相同的目标，其他生态系统之前也经历过这种情况。

Another thing important to Python are extension modules. Extension modules are written in C, and they are usually used to interact with libraries written in other languages (and also sometimes for performance). Poetry, PDM, and Hatchling don’t really support building extension modules. Setuptools does; SciPy and NumPy migrated from their custom numpy.distutils to Meson. The team behind the PyO3 Rust bindings for Python develops Maturin, which allows for building Rust-based extension modules — but it’s not useful if you’re working with C.
对 Python 来说，另一件重要的事情是扩展模块。扩展模块是用 C 语言编写的，它们通常用于与用其他语言编写的库进行交互（有时也用于性能）。Poetry、PDM 和 Hatchling 并不真正支持构建扩展模块。Setuptools 可以;SciPy 和 NumPy 从其自定义的 numpy.distutils 迁移到 Meson。Python 的 PyO3 Rust 绑定背后的团队开发了 Maturin，它允许构建基于 Rust 的扩展模块——但如果你使用 C，它就没有用了。

There weren’t many packaging-related standards that were accepted in 2023. A standard worth mentioning is PEP 668, which allows distributors to prevent pip from working (to avoid breaking distro-owned site packages) by adding an EXTERNALLY-MANAGED file. It was accepted in June 2022, but pip only implemented support for it in January 2023, and many distros already have enabled this feature in 2023. Preventing broken systems is a good thing.
2023 年接受的包装相关标准并不多。一个值得一提的标准是 PEP 668，它允许分发者通过添加 EXTERNALLY-MANAGED 文件来阻止 pip 工作（以避免破坏发行版拥有的网站包）。它于 2022 年 6 月被接受，但 pip 仅在 2023 年 1 月实现了对它的支持，许多发行版已经在 2023 年启用了此功能。防止系统损坏是一件好事。

But some standards did make it through. Minor and small ones aside, the most prominent 2023 standard would be PEP 723: inline script metadata. It allows to add a comment block at the top of the file, that specifies the dependencies and the minimum Python version in a way that can be consumed by tools. Is it super useful? I don’t think so; setting up a project with pyproject.toml would easily allow things to grow. If you’re sending something via a GitHub gist, just make a repo. If you’re sending something by e-mail, just tar the folder. That approach promotes messy programming without source control.
但有些标准确实通过了。撇开小的和小的不谈，最突出的 2023 年标准是 PEP 723：内联脚本元数据。它允许在文件顶部添加一个注释块，以工具可以使用的方式指定依赖项和最低 Python 版本。它超级有用吗？我不这么认为;使用 pyproject.toml 设置项目很容易让事情发展。如果您要通过 GitHub gist 发送内容，只需创建一个存储库即可。如果您通过电子邮件发送内容，只需将文件夹涂上焦油即可。这种方法促进了没有源代码控制的混乱编程。

Learning curves and the deception of “simple”

学习曲线和“简单”的欺骗

Microsoft Word is simple, and a great beginner’s writing tool. You can make text bold with a single click. You can also make it blue in two clicks. But it’s easy to make an inconsistent mess. To make section headers, many users may just make the text bold and a bit bigger, without any consistency or semantics [1]. Making a consistent document with semantic formatting is hard in Word. Adding section numbering requires you to select a heading and turn it into a list. There’s also supposedly some magic involved, that magic doesn’t work for me, and I have to tell Word to update the heading style. Even if you try doing things nicely, Word will randomly break, mess up the styles, mix up styles and inline ad-hoc formatting, and your document may look differently on different computers.
Microsoft Word很简单，是一个伟大的初学者写作工具。您只需单击一下即可将文本加粗。您也可以通过单击两次将其设置为蓝色。但是很容易把不一致的混乱搞得一团糟。为了制作章节标题，许多用户可能只是将文本加粗和放大一点，没有任何一致性或语义 1.在 Word 中很难制作具有语义格式的一致文档。添加节编号需要您选择一个标题并将其转换为列表。据说还涉及一些魔法，这种魔法对我不起作用，我必须告诉 Word 更新标题样式。即使您尝试做得很好，Word 也会随机中断、弄乱样式、混淆样式和内联临时格式，并且您的文档在不同的计算机上看起来可能会有所不同。

LaTeX is very confusing to a beginner, and has a massive learning curve. And you can certainly write \textbf{hello} everywhere. But with some learning, you’ll be producing beautiful documents. You’ll define a \code{} command that makes code monospace and adds a border today, but it might change the background and typeset in Comic Sans tomorrow if you so desire. You’ll use packages that can render code from external files with syntax highlighting. Heading numbering is on by default, but it can easily be disabled for a section. LaTeX can also automatically put new sections on new pages, for example. LaTeX was built for scientific publishing, so it has stellar support for maths and bibliographies, among other things.
LaTeX 对初学者来说非常令人困惑，并且有一个巨大的学习曲线。你当然可以在任何地方写作 \textbf{hello} 。但是通过一些学习，您将制作出精美的文档。今天，您将定义一个 \code{} 命令，该命令使代码为等宽并添加边框，但如果您愿意，它可能会在明天更改 Comic Sans 中的背景和排版。你将使用可以呈现外部文件中代码的包，并突出显示语法。默认情况下，标题编号处于打开状态，但可以很容易地为某个部分禁用它。例如，LaTeX还可以自动将新部分放在新页面上。LaTeX 是为科学出版而构建的，因此它对数学和书目等有很好的支持。

Let’s now talk about programming. Python is simple, and a great beginner’s programming language. You can write hello world in a single line of code. The syntax is simpler, there are no confusing leftovers from C (like the index-based for loop) or machine-level code (like break in switch), no pointers in sight. You also don’t need to write classes at all; you don’t need to write a class only to put a public static void main(String[] args) method there [2]. You don’t need an IDE, you can just write code using any editor (even notepad.exe will do for the first day or so), you can save it as a .py file and run it using python whatever.py.
现在让我们谈谈编程。Python 很简单，是一门很棒的初学者编程语言。您可以在一行代码中编写 hello world。语法更简单，没有 C 语言（如基于 for 索引的循环）或机器级代码（如 break in switch ）的混淆遗留物，看不到指针。您也根本不需要编写类;你不需要写一个类只是为了把一个方法放在那里 public static void main(String[] args) 2.你不需要IDE，你可以使用任何编辑器编写代码（甚至记事本.exe也会在第一天左右完成），你可以将其保存为.py文件并使用运行它 python whatever.py 。

Your code got more complicated? No worry, you can split it into multiple .py files, use import name_of_other_file_without_py and it will just work. Do you need more structure, grouping into folders perhaps? Well, forget about python whatever.py, you must use python -m whatever, and you must cd to where your code is, or mess with PYTHONPATH, or install your thing with pip. This simple yet common action (grouping things into folders) has massively increased complexity.
您的代码变得更复杂了吗？不用担心，您可以将其拆分为多个 .py 文件，使用后即可使用 import name_of_other_file_without_py 。您是否需要更多的结构，也许可以分组到文件夹中？好吧，忘了 python whatever.py ，你必须使用，你必须 cd 到 python -m whatever 你的代码所在的地方，或者弄乱 PYTHONPATH ，或者用 pip 安装你的东西。这个简单而常见的操作（将事物分组到文件夹中）大大增加了复杂性。

The standard library is not enough [3] and you need a third-party dependency? You find some tutorial that tells you to pip install, but pip will now tell you to use apt. And apt may work, but it may give you an ancient version that does not match the tutorial you’re reading. Or it may not have the package. Or the Internet will tell you not to use Python packages from apt. So now you need to learn about venvs (which add more complexity, more things to remember; most tutorials teach activation, venvs are easy to mess up via basic operations like renaming a folder, and you may end up with a venv in git or your code in a venv). Or you need to pick one of the many one-stop-shop tools to manage things.
标准库不够 3 需要第三方依赖？你找到一些教程告诉你， pip install 但现在 pip 会告诉你使用 apt 。并且 apt 可能有效，但它可能会给你一个与你正在阅读的教程不匹配的古老版本。或者它可能没有包。或者 Internet 会告诉您不要使用 apt Python 包。所以现在你需要学习 venv（这增加了更多的复杂性，更多的东西要记住;大多数教程都教激活，venv 很容易通过重命名文件夹等基本操作搞砸，你最终可能会在 git 中得到一个 venv 或你的代码在 venv 中）。或者，您需要从众多一站式工具中选择一种来管理事物。

In other ecosystems, an IDE is often a necessity, even for beginners. The IDE will force you into a project system (maybe not the best or most common one by default, but it will still be a coherent project system). Java will force you to make more than one file with the “1 public class = 1 file” rule, and it will be easy to do so, you won’t even need an import.
在其他生态系统中，IDE 通常是必需的，即使对于初学者也是如此。IDE 将强制您进入一个项目系统（默认情况下可能不是最好或最常见的系统，但它仍然是一个连贯的项目系统）。Java 会强制你用“1 个公共类 = 1 个文件”的规则制作多个文件，而且这样做很容易，你甚至不需要一个 import .

Do you want folders? In Java or C#, you just create a folder in the IDE, and create a class there. The new file may have a different package/namespace, but the IDE will help you to add the correct import/using to the codebase, and there is no risk of you using too many directories (including something like src) or using too few (not making a top-level package for all your code) that will require correcting all imports. The disruption from adding a folder in Java or C# is minimal.
你想要文件夹吗？在 Java 或 C# 中，只需在 IDE 中创建一个文件夹，并在其中创建一个类。新文件可能具有不同的 / ，但 IDE 将帮助您将正确的 package import / using namespace 添加到代码库中，并且不存在使用过多目录（包括类似 src 目录）或使用太少（不为所有代码制作顶级包）的风险，这将需要更正所有导入。在 Java 或 C# 中添加文件夹的干扰很小。

The project system will also handle third-party packages without you needing to think about where they’re downloaded or what a virtual environment is and how to activate it from different contexts. A few clicks and you’re done. And if you don’t like IDEs? Living in the CLI is certainly possible in many ecosystems, they have reasonable CLI tools for common management tasks, as well as building and running your project.
项目系统还将处理第三方包，而无需考虑它们的下载位置或虚拟环境是什么以及如何从不同的上下文中激活它。点击几下，你就完成了。如果你不喜欢IDE？在许多生态系统中，生活在 CLI 中当然是可能的，他们有合理的 CLI 工具来执行常见的管理任务，以及构建和运行您的项目。

PEP 723 solves a very niche problem: dependency management for single-file programs. Improving life for one-off things and messy code was apparently more important to the packaging community than any other improvements for big projects.
PEP 723 解决了一个非常小众的问题：单文件程序的依赖管理。对于打包社区来说，改善一次性事物和混乱代码的生活显然比大型项目的任何其他改进都更重要。

By the way, you could adapt this lesson to static and dynamic typing. Dynamic typing is easier to get started with and requires less typing, but compile-type checking can prevent many bugs — bugs that require higher test coverage to catch with dynamic typing. That’s why the JS world has TypeScript, that’s why mypy/pyright/typing has gained a lot of mindshare in the Python world.
顺便说一句，您可以将本课程调整为静态和动态类型。动态类型更容易上手，并且需要较少的类型，但编译类型检查可以防止许多错误，这些错误需要更高的测试覆盖率才能通过动态类型捕获。这就是为什么 JS 世界有 TypeScript，这就是为什么 mypy/pyright/typing 在 Python 世界中获得了很多关注。

The future… 未来...

Looking at the Python Packaging Discourse, there were some discussions about ways to improve things.
看看 Python 打包话语，有一些关于改进方法的讨论。

For example, this discussion about porting off setup.py was started by Gregory Szorc, who had a long list of complaints, pointing out the issues with the communication from the packaging world, and documentation mess (his post is worth a read, or at least a skim, because it’s long and full of packaging failures). There’s one page which recommends setuptools, another which has four options with Hatchling as a default, and another still promoting Pipenv. We’ve seen this a year ago, nothing changed in that regard. Some people tried finding solutions, some people shared their opinions… and then the Discourse moderator decided to protect his PyPA friends from having to read user feedback and locked the thread.
例如，这个关于移植 setup.py 的讨论是由 Gregory Szorc 发起的，他有一长串的抱怨，指出了包装界的沟通问题，以及文档混乱（他的帖子值得一读，或者至少是略读，因为它很长，充满了打包失败）。有一个页面推荐 setuptools，另一个页面有四个选项，默认为 Hatchling，另一个页面仍在推广 Pipenv。我们在一年前就看到了这一点，在这方面没有任何改变。有些人试图寻找解决方案，有些人分享了他们的意见......然后 Discourse 版主决定保护他的 PyPA 朋友不必阅读用户反馈并锁定线程。

Many other threads about visions were had, like the one about 10-year views or about singular packaging tools. The strategy discussions, based on the user survey, had a second part (the first one concluded in January 2023), but it saw less posts than the first one, and discussions did not continue (and there were discussions about how to hold the discussions). There are plans to create a packaging council — design-by-committee at its finest.
还有许多其他关于愿景的话题，比如关于10年观点或单一包装工具的话题。基于用户调查的策略讨论有第二部分（第一部分于 2023 年 1 月结束），但帖子比第一部分少，讨论没有继续（并且讨论了如何进行讨论）。有计划建立一个包装委员会——最好的委员会设计委员会。

But all those discussions, even when not locked by an overzealous moderator, haven’t had any meaningful effect. The packaging ecosystem is still severely fragmented and confusing. The PyPA docs and tutorials still contradict each other. The PyPA-affiliated tools still have less features than the unaffiliated competition (even the upstart Rye has some form of lockfiles, unlike Hatch or Flit), and going by the PEP 517 build backend usage statistics, they are more popular than the modern PyPA tools. The authors of similar yet competing tools have not joined forces to produce the One True Packaging Tool.
但所有这些讨论，即使没有被过度热心的主持人锁定，也没有产生任何有意义的影响。包装生态系统仍然严重分散和混乱。PyPA 文档和教程仍然相互矛盾。PyPA 附属工具的功能仍然比非附属的竞争对手少（即使是新贵 Rye 也有某种形式的锁文件，不像 Hatch 或 Flit），并且根据 PEP 517 构建后端使用情况统计，它们比现代 PyPA 工具更受欢迎。类似但相互竞争的工具的作者还没有联手生产出一个真正的打包工具。

…is looking pretty bleak

...看起来很凄凉

On the other hand, if you look at the 2023 contribution graphs for most packaging tools, you might be worried about the state of the packaging ecosystem.
另一方面，如果您查看大多数打包工具的 2023 年贡献图，您可能会担心打包生态系统的状况。

• Pip has had a healthy mix of contributors and a lot of commits going into it.
  Pip 拥有健康的贡献者组合和大量的提交。
• Pipenv and setuptools have two lead committers, but still a healthy amount of commits.
  Pipenv 和 setuptools 有两个主要提交者，但仍然有相当数量的提交。
• Hatch, however, is a one-man-show: Ofek Lev (the project founder) made 184 commits, the second place belongs to Dependabot with 6 commits, and the third-place contributor (who is a human) has five commits. The bus factor of Hatch and Hatchling is 1.
  然而，Hatch 是一个独角戏：Ofek Lev（项目创始人）提交了 184 次提交，第二名属于 Dependabot，有 6 次提交，第三名的贡献者（人类）有 5 次提交。Hatch 和 Hatchling 的总线因子为 1。

The non-PyPA tools aren’t doing much better:
非 PyPA 工具的表现也好不到哪里去：

• Poetry has two top contributors, but at least there are four human contributors with a double-digit number of commits.
  Poetry 有两个顶级贡献者，但至少有四个人类贡献者提交了两位数的提交。
• PDM is a one-man-show, like Hatch.
  PDM 是一个独角戏，就像 Hatch 一样。
• Rye has one main contributor, and three with a double-digit number of commits; note it’s pretty new (started in late April 2023) and it’s not as popular as the others.
  Rye 有一个主要贡献者，三个提交次数达到两位数;请注意，它是相当新的（从 2023 年 4 月下旬开始），它不像其他的那么受欢迎。

Conclusion 结论

I understand the PyPA is a loose association of volunteers. It is sometimes said the name Python Packaging Authority was originally a joke. However, they are also the group that maintains all the packaging standards, so they are the authority when it comes to packaging. For example, PEP 668 starts with a warning block saying it’s a historical document, and the up-to-date version of the specification is on PyPA’s site (as well as a bunch of other packaging specs).
我知道PyPA是一个松散的志愿者协会。有时有人说 Python Packaging Authority 这个名字最初是一个笑话。但是，他们也是维护所有包装标准的团体，因此在包装方面他们是权威。例如，PEP 668 以警告块开头，说明它是一份历史文档，并且该规范的最新版本在 PyPA 的网站上（以及一堆其他打包规范）。

The PyPA should shut down or merge some duplicate projects, and work with the community (including maintainers of non-PyPA projects) to build One True Packaging Tool. To make things easier. To avoid writing code that does largely the same thing 5 times. To make sure thousands of projects don’t depend on tools with a bus factor of 1 or 2. To turn packaging from a problem and an insurmountable obstacle to something that just works™, something that an average developer doesn’t need to think about.
PyPA 应该关闭或合并一些重复的项目，并与社区（包括非 PyPA 项目的维护者）合作构建一个真正的打包工具。让事情变得更容易。避免编写 5 次执行基本相同操作的代码。确保数以千计的项目不依赖于总线因子为 1 或 2 的工具。将打包从一个问题和一个不可逾越的障碍变成一个普通开发人员不需要考虑的东西™。

It’s not rocket science. Tons of languages, big and small, have a coherent packaging ecosystem (just read last year’s post for some examples of how simple it can be). Instead of focusing on specifications and governance, focus on producing one comprehensive, usable, user-friendly tool.
这不是火箭科学。大量的语言，无论大小，都有一个连贯的打包生态系统（只需阅读去年的帖子，了解它的简单程度）。与其专注于规范和治理，不如专注于生产一个全面、可用、用户友好的工具。

Discuss below or on Hacker News.
在下面或Hacker News上讨论。

Footnotes 脚注

[1]

Modern Word at least makes this easier, because the heading styles get top billing on the ribbon; they were hidden behind a completely non-obvious combo box that said Normal in Word 2003 and older.

[ 1]现代 Word 至少使这更容易，因为标题样式在功能区上获得了最高计费;它们隐藏在一个完全不明显的组合框后面，该组合框在 Word 2003 及更早版本中显示正常。

[2]

C# 10 removed the requirement to make a class with a Main method, it can pick up one file with top-level statements and make it the entrypoint.

[ 2]C# 10 删除了使用 Main 方法创建类的要求，它可以使用顶级语句拾取一个文件并将其作为入口点。

[3]

The Python standard library gets a lot of praise. It is large compared to C, but nothing special compared to Java or C#. It is also full of low-quality libraries, like http.server or urllib.request, yet some people insist on only using the standard library. The standard library is also less stable and dependable (with constant deprecations and removals, and with new features requiring upgrading all of Python). All the “serious” use-cases, like web development or ML/AI/data science are impossible with just the standard library.

[ 3]Python 标准库得到了很多赞誉。与 C 相比，它很大，但与 Java 或 C# 相比没有什么特别之处。它也充满了低质量的库，比如 http.server 或 urllib.request ，但有些人坚持只使用标准库。标准库的稳定性和可靠性也较差（不断弃用和删除，并且具有需要升级所有 Python 的新功能）。所有“严肃”的用例，如 Web 开发或 ML/AI/数据科学，仅靠标准库是不可能的。