build：Python 包构建的极简前端

build：Python 包构建的极简前端

在 Python 生态中，包构建是一个绕不开的环节。从源码到可分发安装的 wheel 或 sdist，中间需要一个构建前端来协调整个流程。pypa/build 正是 Python Packaging Authority 官方出品的构建前端，定位简单直接：一个正确、简洁的 Python 包构建工具。

Python 包构建的历史几经变迁。在 PEP 517 和 PEP 518 出现之前，开发者习惯直接调用 python setup.py sdist bdist_wheel，但这种方式存在几个固有问题。构建环境可能被本地已安装的第三方包污染，导致构建结果在不同机器上表现不一致。setup.py 本身是可执行代码，调用时 setuptools 的隐式行为不够透明，增加了调试难度。PEP 517 引入了标准化的构建接口，将构建前端和后端解耦，build 正是在这套新标准之上建立的。

build 的工作流程很清晰。在项目根目录执行 python -m build，工具会创建一个隔离的虚拟环境，在其中安装项目声明的构建依赖，然后调用配置好的构建后端生成分发包。默认行为下，它会先生成 sdist，再从 sdist 生成 wheel，最终输出到 dist 目录下。整个过程与当前 Python 环境隔离，不受本地已安装包的干扰，保证了构建的可复现性。

命令行参数设计简洁实用。--sdist 或 --wheel 可以单独指定输出格式；--no-isolation 关闭隔离模式；--outdir 自定义输出目录；--installer 在 pip 和 uv 之间选择隔离环境的创建工具。对于无需构建隔离的场景，--skip-dependency-check 可以跳过依赖检查，配合 --no-isolation 使用，效果等同于 pip 的 --no-build-isolation 参数。

与其他工具的集成是 build 的一大优势。pipx 用户可以直接 pipx run build 一键运行。uv 用户通过 --installer=uv 利用 uv 创建隔离环境，构建速度有明显提升。在 GitHub Actions 等 CI 场景中，cibuildwheel 从 3.0 版本起将 build 作为默认构建前端，只需在 pyproject.toml 中配置 build-frontend = "build[uv]" 即可切换到 uv 模式。conda-forge 生态中，build 以 python-build 的包名提供。

工具定位上，build 保持了刻意克制。它不尝试包揽一切，仅专注于构建流程的编排与调度。实际的构建逻辑完全由各后端完成，build 只是前端调度器。这种职责分离让工具本身保持轻量，也使得在不同构建后端之间切换对用户完全透明。

对于仍在手工编写 setup.py 构建流程的 Python 开发者，迁移到 build 的门槛很低。如果项目已经配置了 pyproject.toml，build 就是最直接的构建方式，无需额外的配置文件或学习新的工作流。