DEVOCEAN

서론

파이썬 패키지 빌드와 관련된 많은 문제들이 있었고, PEP 에서는 이를 해결하기 위한 여러 논의들이 있었습니다.

무엇이 문제였고, 어떻게 개선되어 왔는지에 대한 글들은 많기 때문에 따로 이야기하지 않겠습니다.

이 글에서는 PEP 517과 PEP 518에서 제안하는(거의 표준이 되고있는) build frontend 와 backend 에 대해서 설명을 하고, 관련된 툴들을 살펴보겠습니다.

파이썬 패키지 배포와 설치

일반적으로 파이썬 생태계에서 패키지의 배포와 설치는 아래 그림처럼 이루어집니다.

• source tree: 일반적으로 vcs 에 저장되어 있는 패키지의 소스코드

  ex) https://github.com/pypa/sampleproject

• source distribution(sdist): 릴리즈 된 패키지의 소스코드

  ex) lxml-3.4.4.tar.gz

• binary distribution(wheel): 별도의 컴파일 과정 없이 site-packages 디렉토리에 unpack 만 하면 install 이 끝나는 파일들만을 포함

  ex) chardet-5.1.0-py3-none-any.whl

개발 단계에서는 아래 과정으로 빌드 배포 합니다.

1. source tree 를 Github 에 push

2. ci/cd 에서 source tree 를 checkout 후 sdist 와 wheel 빌드(build)

3. PyPI 에 업로드(twine)

설치 단계에서는 보통 pip 을 이용해서 패키지를 설치하는데 VCS 에서 source tree 를 checkout 받거나, PyPI 에서 sdist 나 wheel 을 다운받아 설치합니다.

빌드는 source tree -> sdist 와 sdist -> wheel 과정을 말하고, 패키지의 개발과 설치 모두에서 발생합니다.

Build frontend 와 backend

Build frontend 는사용자가 빌드할 때 이용하는 도구로 실제 빌드를 하지않고 build backend 를 호출한다고 되어있지만 이 설명만으로는 무엇을 하는지는 알기 힘듭니다.

build frontend 는 다음의 일을 수행해야합니다.

1. pyproject.toml 의 build-system 를 읽고, build requirements 와 build-backend 를 파싱

2. 빌드를 위한 virtualenv 를 구성하고, build requirements 설치

3. build-backend 객체의 build_wheel, build_sdist hook 호출

당연하게도 build-backend 는 build_wheel 과 build_sdist 훅을 구현해야하고,

패키지 개발자는 패키지 빌드에 필요한 정보를 pyproject.toml 의 build-system 테이블에 작성해야합니다.

어떤 객체든 build_wheel 과 build_sdist 훅만 구현하면 build-backend 가 될 수 있고, pyproject.toml 이 아닌 다른 설정 파일을 사용하는 것도 가능합니다.

Tools

build

pypa 에서 배포하는 build frontend

setuptools

과거에는 build frontend 역할도 했지만 지금은 build backend 역할만 수행.

pyproject.toml 뿐만 아니라 setup.py 도 사용 가능하고, C extension 을 이용할 경우 setup.py 가 필요합니다.

build backend 를 따로 지정하지 않으면 setuptools 를 build backend 로 호출한다. pep 621 지원.

flit

pypa 에서 배포하는 툴로서 pure python package 를 명령어 하나로 pypi 에 배포합니다. pep 621지원.

poetry

파이썬 패키지 관리도구로 개발환경 관리, 빌드 및 배포까지 가능하지만 다른 build backend 는 지원하지 않습니다.

따라서 build frontend 라고 할 수 없습니다. 또한 pep 621를 지원하지 않아 이제는 legacy 가 되어가고 있는 것 같습니다.

hatch

pypa 의 패키지 관리도구로 비교적 최근인 2022년 초에 처음 릴리즈되었습니다.

poetry 와 포지션이 거의 겹치지만 최신 pep 스펙을 준수하고, 기능 확장이 쉬워 빠르게 사용자가 늘고 있습니다.

black, fastapi, uvicorn, pydantic, tox 등의 굵직한 project 에서 이용중입니다.

마치며

파이썬 패키지 build frontend 의 경우 pyproject.toml 의 build-system 테이블을 읽고 backend 호출이라는 명확하고,

단순한 기능만을 갖고 있어서 개발 단계의 build 와 설치 단계의 pip 외에는 특별히 다른 구현체가 있을 필요가 없을 것 같습니다.

build backend 기능을 포함한 파이썬 패키지 관리 도구들이 많이 있는데요.

가장 인기있는 도구 중 하나였던 poetry 가 pep 를 준수하지 않고 고집을 부리는 동안 hatch 같은 신생 도구에게 기회를 주고 있는 것 같습니다.