最近，我正在为 Red Hat 工作的当前项目中执行一项非常具体的任务，即 RHEL Lightspeed
Shellai，这个项目相对较新，但我们想开始发货
开发 RPM，让我们的 QE 朋友开始使用该工具并在他们的管道中进行测试。
我知道包装和一般Python东西的方法，但是伙计，我必须告诉你，这个包装任务花了我两个时间
一整天都可以度过。让我快速引导您完成任务的详细信息。
TLDR；最终一切顺利，这就是最终的 PR：https://github.com/rhel-lightspeed/shellai/pull/4
任务详情
命令行助手项目计划在 RHEL 9 和即将推出的 RHEL 10 下发布。
根据上面的陈述，如果您之前已经使用过 RHEL，那么您已经猜到挑战将是
RHEL 中依赖项的版本。
- RHEL 9 有 python 3.9
- 最后，RHEL 10 有 Python 3.12
我们还希望相对频繁地进行开发构建，以便在我们进行测试时测试新功能
开发工具。
对于开发部分，我们希望使用 pdm 来管理我们的依赖项
构建。当我们完成任务时，我们注意到 pdm 后端未在 RHEL 存储库中提供，因此我们
使用默认的 setuptools 构建后端。
由于我们的系统目标“相对较新”，我们希望使项目现代化并确保我们正在使用
新的工具/结构和格式。为此，我们选择使用 pyproject.toml，因为它是通过 pdm init 生成的
当我们启动该项目时。
构建 RPM 时遇到的问题
最初，我们的想法是使用最新的 python 功能和项目结构，例如 pyproject.toml 文件
而不是旧的 setup.py。当你开始一个新项目时，一切都很酷而且很新，你会很兴奋地使用
那个东西，唯一的问题是：
- 它们非常适合开发过程，但不适合打包。
最初，当我开始任务时，我认为我们可以使用新的 RPM 宏来构建项目，因为我们
使用 pyproject.toml 和 pdm 来管理依赖项。
为此，Fedora 文档有一篇不错的文章，名为 Python Packaging
详细指导方针。当导游
几乎涵盖了您可能需要的所有主题和案例，甚至还有示例
规格文件。
由于我们的主要目标是 RHEL，我们可以想象遵循指南中的所有内容都可以按原样工作，对吗？没有。
其原因在于 RHEL 存储库中提供的版本。即使新的宏指向
该指南可能在构建期间起作用，您将无法在以下目标中生成最终 RPM：
- RHEL 9 将能够完成大部分步骤，但会失败 %pyproject_wheel，因为它将构建一个包 名字未知。发生这种情况是因为（再次）RHEL 9 下提供的 python3-setuptools 很旧。它 无法识别 pyproject.toml 规范生成的大部分元数据。
解决方案
我们必须创造遗产
setup.py 文件以便
Python 轮构建的进展，并避免 pyproject.toml 和我们的旧版本之间的数据重复
setup.py 文件中，我们使用了 tomllib，因为以下原因：
- Python 3.11 之后，tomllib 原生捆绑到标准库中
正如您在上面所看到的，我们使用 tomllib 加载 pyproject.toml 文件并读取必要的字段，然后简单
更新我们的旧版 setup.py。这样，我们就可以修改 pyproject.toml，并且每当我们推送新版本时，我们都会
也能够在我们的旧版 setup.py 中保持一致性。
关于specfile，我们不得不返回并使用文档中所谓的“201x-era”Python 打包
指导方针。本质上，我们正在使用好的
旧的 python setup.py build … 命令（显然是通过宏）来构建项目。
该解决方案使我们能够在我们想要支持的 RHEL 版本之间保持一致性，同时保持
使用 pdm 和我们希望开发的闪亮新功能。
