当前Python打包生态的标准化

起源：终结配置碎片化

2016年，Python社区面临严重的配置碎片化问题：

• 每个工具都有自己的配置文件（setup.py, requirements.txt, MANIFEST.in, .flake8等）
• 动态执行的setup.py带来安全风险

PEP 518（2016）首次提出pyproject.toml概念，核心目标：

1. 声明构建依赖（解决鸡生蛋问题）
2. 提供统一配置入口
3. 替代易出错的setup.py

关键推动者：

• Donald Stufft（PyPA核心成员）
• Nick Coghlan（Python核心开发者）
• Poetry/Flit等现代工具开发者

“我们需要一个不会执行任意代码的静态配置文件” —— PEP 518设计原则

---

核心功能与使用指南

基础结构（所有项目必备）

[build-system]
requires = ["setuptools>=64.0.0", "wheel"]  # 构建依赖
build-backend = "setuptools.build_meta"    # 构建后端

项目元数据（PEP 621标准）

[project]
name = "my_project"
version = "1.0.0"
description = "革命性Python项目"
dependencies = ["requests>=2.25", "numpy"]  # 替代requirements.txt

[project.optional-dependencies]
test = ["pytest>=7.0"]
dev = ["black", "mypy"]

工具集成（收敛碎片化配置）

[tool.pytest.ini_options]
minversion = "7.0"
addopts = "-vv"

[tool.black]
line-length = 88
target-version = ["py310"]

[tool.mypy]
strict = true

---

解决的核心问题

问题类型	旧方案	pyproject.toml方案
构建依赖	setup.py动态安装	静态声明[build-system]
元数据分散	setup.py+setup.cfg	统一[project]节
工具配置碎片	10+个配置文件	统一[tool.*]命名空间
安全风险	setup.py可执行代码	纯声明式配置

---

版本支持时间线

• 2016.05：PEP 518提出规范（Python 3.5+）
• 2018：pip 10.0+ 支持构建隔离
• 2020：PEP 621标准化[project]节
• 2021：setuptools 61.0+ 原生支持
• 2023：90%+主流工具支持（pytest, black, mypy等）

关键转折点：Python 3.11起官方文档推荐为首选配置

---

迁移实战指南

从setup.py迁移

# 旧方案
# setup.py
from setuptools import setup
setup(
    name="old_project",
    install_requires=["requests"]
)

# 新方案 → pyproject.toml
[project]
name = "new_project"
dependencies = ["requests"]

多工具配置合并

# 替代.cfg/.ini文件集群
[tool.isort]
profile = "black"

[tool.pylint]
max-line-length = 120

[tool.coverage.run]
source = ["src"]

---

未来演进方向

1. PEP 660：可编辑安装标准化
2. 动态版本支持：从Git tag自动派生版本
3. 跨语言扩展：Rust/Python混合项目支持

“就像package.json之于Node.js，pyproject.toml正在成为Python项目的身份证明” —— PyPA技术报告

开发者行动建议

1. 新项目：必须使用pyproject.toml
2. 旧项目迁移：
   • 先添加[build-system]
   • 逐步迁移[project]元数据
   • 用[tool.*]替换分散配置
3. 工具选择：优先支持PEP 621标准的工具（如PDM/Flit）

通过标准化配置入口，pyproject.toml结束了Python打包的"黑暗时代"，为生态系统带来了前所未有的统一性和安全性。