如何在不使用 setup.py 文件的情况下构建源代码分发版？

Question

具有以下包结构

.
??? my_package
?   ??? __init__.py
??? setup.cfg
??? setup.py

的内容 setup.py

from setuptools import setup
setup()

的内容 setup.cfg

[metadata]
name = my_package
version = 0.1

[options]
packages = find:

我可以my_package像这样构建轮子或源代码分发

pip wheel --no-deps -w dist .
# generates file ./dist/my_package-0.1-py3-none-any.whl
python setup.py sdist
# generates file ./dist/my_package-0.1.tar.gz

但是根据setuptools 的维护者的说法，声明式构建配置是理想的，使用命令式构建将是一种代码味道。所以我们替换setup.py为pyproject.toml：

.
??? my_package
?   ??? __init__.py
??? setup.cfg
??? pyproject.toml

的内容 pyproject.toml

[build-system]
build-backend = "setuptools.build_meta"
requires = ["setuptools", "wheel"]

你仍然可以像以前一样构建一个轮子，它可以工作。但是 sdist 不起作用：

python: can't open file 'setup.py': [Errno 2] No such file or directory

那么您应该如何使用 setuptools实际构建 .tar.gz 文件？什么是面向用户的创建 sdist 的工具？我不想更改构建后端。看起来其他打包工具都编写了自己的构建入口点，但我认为在元数据中定义声明性构建系统的全部意义在于，您不必亲自动手构建系统，了解每个不同的打包工具期望被调用或必须进入解释器并手动调用 Python API。但是构建系统要求的 PEP 现在已经超过 2 年了。我在这里遗漏了一些明显的东西吗？

如何在不使用setup.py文件的情况下构建源代码分发？

Answer 1

这是一个有点争议的话题，目前的答案是，没有一种工具是每个人都同意的构建源代码发行版的“正确方法”，也没有一种工具是什么。您可以在 Python Packaging discourse 上看到有关它的长篇幅。

我不愿提供太多耐用格式的包装建议，因为沙子总是在变化，但截至 2019 年 11 月，setup.py sdist它并未被弃用，但它确实具有 PE​​P 517 和 PEP 518 旨在修复的所有缺点——即你有自己创建构建环境（并了解所有构建依赖项），并且它仅适用于 setuptools/distutils 及其等效项。

这不是“官方”建议，而是当前（2020 年 12 月）的最佳替代品，setup.py sdist并且setup.py bdist_wheel正在使用pypa-build。安装一次

pip install build

并用作

python -m build --sdist --wheel

这同时构建了源代码分发和轮子。这就是我构建 PEP 517 兼容包的方式。

这要求您的项目有pyproject.toml,pyproject.toml必须有build-system.requires和build-system.build-backend密钥，但它适用于具有 PE​​P 517 兼容后端（包括flit）的任何项目。

其他工具

为什么不使用flit或poetry或hatch？这些工具都可供想要使用它们的人使用，但它们不是这个问题的答案。这个问题是询问setuptools使用声明性setup.cfg格式构建的项目。既不作为通用 PEP 517 构建前端，flit也不poetry作为通用的 PEP 517 构建前端，因此它们仅用作使用各自后端的项目的构建命令。

我不熟悉不够用hatch说它是否能与后端管理项目等比setuptools的，但（再次，为2019年11月），它是不是一个PEP 517前端，也不会工作，如果你没有a setup.py（它会引发错误“无法打开文件 setup.py”，并且会忽略您的pyproject.toml文件）。