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

그렇다면 실제로 setuptools를 사용하여 .tar.gz 파일 을 어떻게 만들어야 합니까? Sdist를 생성하는 사용자를위한 도구는 무엇입니까? 빌드 백엔드를 변경하고 싶지 않습니다. 다른 패키징 도구는 모두 자체 빌드 진입 점을 작성하는 것처럼 보이지만 메타 데이터에서 선언적 빌드 시스템을 정의하는 요점은 빌드 시스템을 직접 익힐 필요가 없으므로 각 방법을 배우는 것입니다. 다른 패키징 도구가 호출되거나 인터프리터로 이동하여 Python API를 수동으로 호출해야합니다. 그러나 빌드 시스템 요구 사항에 대한 PEP는 2 년이 넘었습니다. 여기에 명백한 것이 빠져 있습니까?

setup.py파일 을 사용하지 않고 소스 배포판을 작성하는 방법은 무엇입니까?

이것은 다소 논란의 여지가있는 주제이며, 현재로서는 모든 사람이 소스 배포판을 구축하는 "올바른 방법"이 아니고 그 도구가 무엇인지에 동의하는 단일 도구가 없다는 것입니다. 파이썬 패키징 담론에서 그것에 대한 긴 실을 볼 수 있습니다 .

나는 모래가 항상 변화하기 때문에 내구성이 형식에 너무 많은 포장 조언을 주저하지만, 년 11 월 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형식 을 사용하는 프로젝트 빌드에 대해 묻습니다 . 일반적인 PEP 517 빌드 프론트 엔드 역할 flit도 poetry수행 하지 않으며 , 따라서 해당 백엔드를 사용하는 프로젝트의 빌드 명령으로 만 작동합니다.

내가 익숙하지 충분히 생각 hatch이 백엔드와 함께 프로젝트를 관리 할 수 있는지 여부를 말할 기타 (2019 년 11 월으로, 다시) setuptools에 비해 있지만, 그것은 것입니다 하지 격려 (517) 프론트 엔드, 그리고 작업, 당신은하지하지 않을 경우 a setup.py( "setup.py 파일을 열 수 없습니다"라는 오류가 발생하고 pyproject.toml파일 을 무시합니다 ).

파이썬 패키징과 관련하여 "명백한"것은 없습니다. 사실, 당분간, 적어도 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

Flitpyproject.toml 과 같은를 통해 활성화 된 대체 빌드 시스템 중 하나를 시도 할 수도 있습니다 .