如何在现代Python打包中实现构建时代码生成及相关技术疑问

1. 构建时代码生成的实现思路 #

要在构建阶段把数据文件编译成代码并打包到sdist/wheel中，确实需要基于PEP517实现自定义构建后端。你提到的pyproject.toml配置是正确的：

[build-system]
build-backend = "local_backend"
backend-path = ["backend"]

自定义后端需要实现PEP517规定的核心接口：build_sdist()、build_wheel()，以及可选的get_requires_for_build_sdist()、get_requires_for_build_wheel()等。

2. 是否需要委托现有构建后端？ #

完全可以——从零实现所有打包逻辑成本很高，推荐基于成熟后端（比如setuptools、poetry-core）做二次封装。比如在自定义后端的build_wheel()方法里，先执行代码生成步骤，再调用setuptools的后端完成实际打包。

3. 仅用pyproject.toml的非平凡构建示例 #

这类项目确实相对少见，但可以参考：

• 部分使用maturin的Python-Rust绑定项目：仅通过pyproject.toml配置，构建时自动编译Rust代码并生成Python绑定，属于典型的构建时代码生成场景。
• pydantic的部分子项目：通过自定义后端在构建阶段生成类型相关代码，全程依赖pyproject.toml完成配置与构建。

4. PEP517前端与后端的重叠情况 #

你的判断是对的，很多工具确实同时扮演前端和后端的角色：

• 前端：负责调用后端的构建接口（比如pip build、build工具）。
• 后端：实现PEP517的构建逻辑（比如setuptools、poetry-core）。
  比如poetry既是前端（提供poetry build命令），也自带专属后端；setuptools作为后端，也可以配合pip build这类前端使用。

内容的提问来源于stack exchange，提问作者Masklinn