英文 | Python packaging - Growing Pains
原作 | BERNAT GABOR
译者 | 豌豆花下猫
在前两篇文章中, 我介绍了 Python 具有的包类型以及包的构建方式, 尤其介绍了 PEP-517/518. 尽管这些更改主要是为了使打包变得更健壮, 但是在实施和发布时, 我们却遇到了一些问题. 这篇文章将介绍一部分, 希望可以为大家提供经验教训, 并提出一些有趣的问题以待将来解决.
查看 PEP-517 和 PEP-518 的改动, 可以认为构建后端 (亦即 setuptools,flit) 几乎没有做什么, 只是通过 Python 模块提供了功能接口. 大部分繁重的工作都在构建前端上, 它需要生成隔离的 Python, 然后以新的方式调用构建后端. 如今当我们谈论构建前端时, 我们的选项主要是 pip 或 poetry(和开发者的 tox).
这些项目由社区维护, 由少数活跃的开发者在空闲时间维护. 他们并没有因此获得报酬, 而且需要谨慎考虑这些工具被使用的多种方式. 考虑到这一点, 在 PEP 被接受之后, 还花了几乎两年时间才首次实施就不足为奇了. 计划, 测试和实施已经在背后进行了一年多.
但是, 尽管做了所有准备工作, 不可避免的是, 第一版确实破坏了一些软件包, 在大多数情况下, 人们做的某些操作使维护人员感到惊讶. 让我们试着了解其中一些例子, 以及它们是如何被解决的.
Mink Mingle 摄 / Unsplash-- 准备好出发!
PEP-518
此 PEP 引入了 TOML 文件格式.[2] 一种专门为了易于读 / 写配置而创建的格式. 尽管在 build-system 部分下介绍了打包配置, 但其它工具可以自由地将其配置放在 tool:name 部分下, 因为它们拥有 PyPi 命名空间中的名字. 各种工具立即开始利用这一点(例如 Towncrier[3] , black[4] 等).
来源: http://www.tuicool.com/articles/N7rQ7r2