仅依赖pyproject.toml打包Python程序的弊端及为何使用setup.py/setup.cfg

仅用pyproject.toml的弊端 #

• 缺乏动态配置能力：pyproject.toml是纯静态配置文件，没法像setup.py那样编写Python代码实现动态逻辑。比如根据当前操作系统自动调整依赖列表、从Git标签自动生成版本号、或根据环境变量决定是否包含可选组件，这类需求pyproject.toml完全满足不了——它只能写死固定值。
• 旧工具兼容性差：不少老版本的打包工具、CI/CD脚本或第三方服务还没完全适配pyproject.toml。比如有些旧环境里的pip版本不支持从pyproject.toml读取元数据，或是自动化部署脚本依然依赖python setup.py sdist这类传统命令，纯用pyproject.toml会导致这些场景直接失效。
• 高级打包功能缺失：虽然PEP 621把大部分元数据迁移到了pyproject.toml，但很多高级功能还是依赖setup.py或setup.cfg。比如编译C扩展模块时，需要用setuptools的Extension类配置编译参数，这些逻辑只能写在setup.py里；还有自定义打包命令（比如自定义的构建、上传步骤），也得靠setup.py的代码实现。

为何仍需setup.py或setup.cfg #

• 处理复杂/动态场景：当项目需要动态调整打包配置时，setup.py的Python代码是唯一选择。比如根据用户的Python版本自动排除不兼容的依赖、从外部文件读取版本信息、或在打包前自动生成某些资源文件，这些都得靠setup.py完成。setup.cfg虽然也是静态配置，但它支持更多setuptools的特有配置项，部分还没迁移到pyproject.toml中。
• 向后兼容旧生态：很多成熟项目的工具链、部署流程都是基于setup.py搭建的。保留setup.py可以确保旧的CI脚本、依赖管理工具依然正常工作，不用一次性重构整个打包流程。
• 支持高级构建需求：对于涉及C扩展、SWIG绑定、自定义编译步骤的项目，setup.py是必不可少的。pyproject.toml只是用来指定构建后端（比如setuptools），但具体的构建逻辑还是得由setup.py里的代码定义。

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