Com a seguinte estrutura de pacotes
.
├── my_package
│ └── __init__.py
├── setup.cfg
└── setup.py
Conteúdo de setup.py
from setuptools import setup
setup()
Conteúdo de setup.cfg
[metadata]
name = my_package
version = 0.1
[options]
packages = find:
Eu posso construir rodas ou uma distribuição de fontes para my_package
isso
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
Mas, de acordo com o mantenedor do setuptools , uma configuração de compilação declarativa é ideal e usar uma compilação imperativa será um cheiro de código. Então substituímos setup.py
por pyproject.toml
:
.
├── my_package
│ └── __init__.py
├── setup.cfg
└── pyproject.toml
Conteúdo de pyproject.toml
[build-system]
build-backend = "setuptools.build_meta"
requires = ["setuptools", "wheel"]
E você ainda pode montar uma roda da mesma maneira que antes, ela funciona. Mas sdist não funciona:
python: can't open file 'setup.py': [Errno 2] No such file or directory
Então, como você realmente deve criar o arquivo .tar.gz usando o setuptools ? Qual é a ferramenta voltada ao usuário para criar sdist? Não quero alterar o back-end da compilação. Parece que outras ferramentas de empacotamento escrevem seus próprios pontos de entrada de construção, mas achei que o objetivo principal de definir um sistema declarativo de construção nos metadados era para que você não precisasse trabalhar com o sistema de construção, aprendendo como cada espera-se que uma ferramenta de empacotamento diferente seja chamada ou precise entrar no interpretador e chamar uma API Python manualmente. Mas o PEP para requisitos de sistema de compilação já tem mais de 2 anos. Estou perdendo algo óbvio aqui?
Como criar uma distribuição de origem sem usar o setup.py
arquivo?
pep517.build
que é apenas um experimento, uma muleta temporária quando existem ferramentas produtivas como esvoaçante, poesia, escotilha e provavelmente até mais?