pyproject.toml을 이용한 파이썬 패키징 (1) - setup.py의 문제

지금까지 파이썬 프로젝트의 패키징은 setuptools의 setup.py를 사용하는 것이 일반적이었다.

 

setup.py를 사용한 파이썬 프로젝트 폴더 구성은 아래 문서를 참고한다.

파이썬 프로젝트 폴더 구성하기

 

setup.py를 사용한 파이썬 프로젝트의 예제 코드는 아래 문서를 참고한다.

Jenkins 파이썬 빌드 구성의 예제 코드 만들기 (1)

 

그러나 현재는 pyproject.toml의 사용이 권장되고, setup.py 사용을 자제하는 것이 권고되고 있다.

따라서 기존 setup.py를 pyproject.toml로 변경해야 하며, 빌드와 배포에서도 변경이 필요하다.

 

간단하게 setup.py와 setuptools에 대해 살펴보고, pyproject.toml에 대한 적용법을 정리한다.

 

 

setup.py?

파이썬 패키징

파이썬 패키징에 대해 간략히 살펴본다.

 

구체적인 파이썬 패키징의 변화는 아래 글에 정리가 잘 되어 있으므로 참고한다.

파이썬 패키징의 과거, 현재, 그리고 미래

 

아래 내용은 위의 글을 기반으로 조사한 내용을 간략하게 정리한 것이다.

 

distutils의 등장

최초 등장한 것은 distutils이며, setup.py 스크립트를 사용하는 형태이다.

setup.py에 distutils를 임포트하고 패키지의 메타데이터를 작성한다.

이후 쉘에서 python 명령어를 통해 setup.py를 실행하는 형태로 되어 있다.

$ python setup.py sdist    # 패키지 소스코드 압축
$ python setup.py bdist    # 패키지 바이너리 배포판 생성
$ python setup.py install    # 패키지 설치

 

지금 사용하는 바이너리 배포판 명령어와 동일한 것을 확인할 수 있다.

 

distutils는 아래 기능만 수행했다.

• 소스코드의 패키징
• 패키지의 설치

패키지의 다운로드와 의존성 처리는 제공하지 않았다.

 

distutils는 2000년에 파이썬 1.6의 기본 패키지로 포함되었다.

그러나 setuptools와 pip로 인해 distutils는 3.10  버전에서 deprecated, 3.12 버전에서 제거되었다.

 

pypi 저장소 등장

생성한 패키지를 공유하기 위해 중앙 서버인 PyPI 서버가 2003년 등장한다.

2005년부터는 직접 파이썬 패키지들을 호스팅하는 형태로 변경되어 현재까지 이어지고 있다.

 

문제는 distutils가 패키지 다운로드를 제공하지 않았다는 것이다.

따라서 사용자는 직접 패키지를 다운로드하고 distutils 명령으로 설치하는 번거로운 과정이 필요했다.

아직 pip와 whl은 등장하지 않았다.

 

 

setuptools와 easy_install의 등장

distutils의 불편함을 해소하기 위해 2004년 setuptools가 탄생했다.

distutils가 제공하던 패키지 빌드와 설치 기능에 패키지 테스트, PyPI 업로드 등의 기능이 추가되었다.

기존의 setup.py 형식을 그대로 사용하면서, 아래 기능들이 추가되었다.

• 의존성 설정 (install_requires, test_requires 등)
• 엔트리포인트 설정 (entry_points)
• 파이썬 버전 지정 (python_requires)

 

easy_install 도구도 setuptools에 포함되어 제공되었다.

PyPI에 업로드 된 패키지를 의존성을 포함하여 설치하는 기능을 제공했다.

그러나 패키지를 삭제하거나 설치 된 패키지 목록 출력 등의 기능이 없었다.

 

이후 setuptools는 빌드와 업로드, easy_install은 다운로드와 설치 기능을 제공하는 것으로 역할이 구분되었다.

그러나 pip의 등장으로 인해 easy_install은 2021년 상반기에 setuptools에서 제거되었다.

 

pip의 등장

easy_install이 패키지 삭제, 목록 출력 등의 기능을 지원하지 않는 단점을 보완하기 위해 2008년에 등장했다.

 

파이썬 3.4 버전부터 기본 인스톨러에 포함되어, 파이썬 인스톨러의 표준으로 사용되고 있다.

관련 PEP 문서는 아래 링크를 참고한다.

PEP 453 – Explicit bootstrapping of pip in Python installations | peps.python.org

 

wheel의 등장

초기의 pip는 소스코드를 직접 빌드하는 형태로 설치했다.

C  기반의 파이썬 패키지는 해당 컴파일러 없이 빌드가 되지 않는 단점이 있었다.

따라서 zip 압축 파일 형태의 바이너리 패키지를 지원하는 wheel 포맷이 2013년에 탄생했다.

 

관련 PEP 문서는 아래 링크를 참고한다.

PEP 427 – The Wheel Binary Package Format 1.0 | peps.python.org

 

 

setup.py 의 문제

여기까지 보면 현재 우리가 사용하고 있는 setup.py, setuptools, pip, wheel 등이 모두 등장했다.

 

그러나 몇 가지 문제점이 존재한다.

• setuptools는 파이썬의 공식 빌드 도구가 아니다.  누구나 PEP를 준수하는 빌드 시스템을 만들 수 있다.
• 여전히 setup.py에 의존적이다. setup.py는 2000년 distutils와 함께 등장했다.
• 심지어 setup.py를 python 명령으로 실행한다. 메타데이터 파일인지 파이썬 스크립트인지 모호하다.
• setup.py의 setup 함수는 setuptools에 정의되어 있다.
• 따라서 setup.py를 파싱하려면 setuptools가 필요하다.
• pip를 사용하더라도 setuptools가 없으면 설치가 불가능할 수 있다.
• 게다가 setup.py의 일부 기능은 setuptools의 버전에 따라 실행되지 않는 문제도 존재한다.

 

setup.py를 직접 실행하면 안되는 이유는 아래 문서에 잘 정리되어있다.

Paul Ganssle - Why you shouldn't invoke setup.py directly

 

요약하면 setup.py로 인해 setuptools는 빌드 프론트엔드와 백엔드를 모두 수행해야 하는 문제가 있다는 것이다.

• 빌드 프론트엔드 - 빌드 환경 확인, 패키지 메타 정보 검증, 빌드 백엔드 호출
• 빌드 백엔드 - 소스코드 가져오기, 패키지 바이너리로 변환

Python package 의 build frontend 와 backend는 아래 문서에 잘 정리되어 있으므로 참고한다.

Python package 의 build frontend 와 backend

 

패키지의 메타데이터를 정의하는 setup.py가 setuptools라는 특정 빌드 도구에 종속 된 것이 근본적인 문제이다.

 

pyproject.toml의 등장

이러한 setup.py의 문제를 해결하기 위해 등장한 것이 pyproject.toml이다.

 

해당 내용은 아래 문서를 참고한다.

pyproject.toml을 이용한 파이썬 패키징 (2) - pyproject.toml의 등장