Как построить исходный дистрибутив без использования файла setup.py?

Со следующей структурой пакета

.
├── 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

Так как же вам на самом деле собрать файл .tar.gz с помощью setuptools ? Что такое инструмент для создания sdist? Я не хочу менять бэкэнд сборки. Похоже, что все другие инструменты упаковки пишут свои собственные точки входа в сборку, но я думал, что весь смысл определения декларативной системы сборки в метаданных заключается в том, чтобы вам не приходилось практиковаться в системе сборки, изучая, как каждый другой инструмент упаковки ожидает вызова или необходимости входить в интерпретатор и вызывать Python API вручную. Но PEP для требований к системе сборки уже более 2 лет. Я что-то упускаю здесь очевидное?

Как построить исходный дистрибутив без использования setup.pyфайла?

Это несколько спорная тема, и ответ на данный момент заключается в том, что нет единого инструмента, с которым все согласны, является «правильный путь» для создания исходных дистрибутивов, и каким бы он ни был. Вы можете увидеть длинную ветку об этом в дискурсе Python Packaging .

Я не решаюсь дать слишком много советов упаковки в прочных форматах , потому что песок всегда меняется, но по состоянию на ноябрь 2019 года, setup.py sdistявляется не рекомендуется, но это действительно имеет все недостатки , которые PEP 517 и PEP 518 были предназначены для исправления - а именно , что у вас есть создать среду сборки самостоятельно (и знать обо всех зависимостях сборки), и она работает только с setuptools / distutils и их эквивалентами.

Это не «официальная» рекомендация, но текущая лучшая замена для setup.py sdistи setup.py bdist_wheelиспользует версию командной строки pep517. Замена для sdist:

python -m pep517.build --source .

Вы можете одновременно создать колесо и исходный код:

python -m pep517.build --source --binary .

Вот как я собираю свои PEP 517-совместимые пакеты.

Это требует , чтобы ваш проекта есть pyproject.toml, и pyproject.tomlдолжна иметь build-system.requiresи build-system.build-backendключи, но он будет работать для любого проекта с PEP 517-совместимым бэкэндом ( в том числе flit).

Другие инструменты :

Почему бы не использовать flitили poetryили hatch? Все эти инструменты доступны для тех, кто хочет их использовать, но они не являются ответом на этот вопрос . Этот вопрос задают о проектах, построенных с setuptoolsиспользованием декларативного setup.cfgформата. Ни то, flitни другое не poetryдействуют как универсальные внешние интерфейсы сборки PEP 517, и поэтому они работают только как команды сборки для проектов, использующих свои соответствующие внутренние серверы.

Я не достаточно знаком с тем, hatchчтобы сказать, может ли он управлять проектами с бэкэндами, отличными от setuptools, но (опять же, по состоянию на ноябрь 2019 года), это не интерфейс PEP 517, и он не будет работать, если у вас нет а setup.py(это вызовет ошибку «не могу открыть файл setup.py» и проигнорирует ваш pyproject.tomlфайл).

Там нет ничего "очевидного", когда дело доходит до упаковки Python. Действительно, на данный момент, по крайней мере, если вы используете distutils / setuptools, необходимо создать (почти) пустой setup.pyфайл, даже если вы используете полностью декларативный setup.cfg:

#!/usr/bin/env python
from setuptools import setup
setup()

Я также рекомендую chmod +x setup.py.

В этом случае вы просто пишете «точку входа» в систему сборки самостоятельно, и setup()это просто main()функция для нее - но теперь вместо этого setup()можно прочитать все аргументы, которые традиционно передавались setup.cfg.

Теперь вы все еще можете использовать, setup.py sdistесли хотите сделать архив с исходным кодом:

./setup.py sdist

Вы также можете попробовать одну из альтернативных систем сборки, которые включены через pyproject.toml, например, Flit .