Python 패키징의 역사

pyproject.toml 파일을 보고 찾아보다 파이썬 패키징의 역사까지 보게되었다.

 

1. distutils 패키징의 시작

파이썬은 1991년 처음 만들어졌다. 업계에서는 상당히 옛날이다. 자바 보다 5년 빠르고 구글 검색엔진보다 6년이나 빠르다.

그래서 지금은 당연히 패키징 저장소가 달려있지만 그 당시에는 패키지 저장소는 물론 패키지를 검색할 수 있는 검색엔진조차도 없었다.

그래서 이 당시 파이썬 개발자들은 파르나소스의 금고 라는 일종의 커뮤니티 사이트를 통해서 패키지를 공유했다.

문제는 패키지를 설치하는 정해진 방법이 없다보니 각자 설치법을 담은 문서를 패키지와 함께 공유하는 수밖에 없었다.

예를들어 "abc"라는 패키지를 쓰기위해서 어떤 코드를 어디어디에 넣어라는 식으로 말이다.

 

이런 상황에 불편함을 느껴 1998년 파이썬 코드를 패키징하고 빌드할수있는 distutils 라는 패키지를 만들게 된다.

setup.py 라는 패키지의 메타데이터를 담은 파이썬 스크립트를 사용하는 방식을 제시했다. 그 스크립트들을 이용해서 패키지를 배포하고 설치하는 표준화된 방법을 제공했다.

from distutils.core import setup

setup(name='foo', version='1.0', py_modules=['foo'],)

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

위의 예시를 활용함으로써 개발자들은 쉽게 패키지를 공유 가능한 형태로 만들 수 있게 되었고 사용하는 패키지를 공통된 방법으로 설치를 할 수 있게 되었다. 2000년 에 distutils는 파이썬 1.6에 표준 라이브러리로 포함된다.

 

2. PyPI 패키지 저장소의 등장

이제 패키지를 빌드하고 설치하는 과정은 표준화 되었다. 그 다음 문제로는 어디서 패키지를 검색할 수 있는지였다.

여전히 커뮤니티 사이트 등에서 패키지를 공유하고 있어 사용자 입장에서는 자신에게 필요한 패키지를 어디에서 찾아야 할 지 문제였다.

이래서 탄생한 것이 2003년 파이썬 패키지들의 중앙 인덱스 서버인 PyPI(Python Packaging Index)가 탄생한다.

PyPI는 파이썬 패키지를 쉽게 찾을 수 있게하는 목적으로 탄생했으므로 초기에는 패키지들의 메타데이터 정보들만 제공하는데 초점을 맞췄다. 그래서 찾은 패키지를 다운로드 받기위해서는 다시 외부 사이트에서 받아야하는 단점이 존재했다.

그런 불편함과 패키지를 외부 도메인에서 호스팅 하는 것은 보안 취약점 문제가 있으므로 2005년부터는 PyPI에서 패키지를 직접 다운로드 가능하게 했다.

 

3. setuptools 새로운 빌드 시스템과 패키지 설치도구

이제 빌드,설치,검색 모두 표준화 되었다. 하지만 distutils는 PyPI에서 패키지를 다운 받을 수 없고 패키지간의 의존성 처리도 할 수없는 단순히 소스코드를 패키징하고 설치하는 기능이 전부인 라이브러리였다. 그래서 탄생한 것이 2004년 setuptools이다.

setuptools는 distutils의 확장판이라고 볼 수 있다 기본 distutils의 기능에 PyPI에 패키지를 업로드 하거나 패키지에 대한 테스트를 수행하는  등 부가 기능을 제공했다.

from setuptools import setup, find_packages

setup(
    name = 'foo',
    version = '1.0',
    install_requires=['dependency'],
    entry_points={},
    python_requires=">=2.4",
)

위의 예시대로 setup.py의 포맷을 그대로 사용하되 문법을 확장하여 의존성, 파이썬 버전, 엔트리 포인트 등을 설정하는 기능을 추가하였다.

또한 easy_install이라는 도구를 함께 제공했다. 직접 PyPI에서 다운로드 받지 않고도 쉽게 PyPI에 업로드된 패키지를 의존성을 포함하여 설치하는 기능을 제공했다. 또한 큰 의미로는 파이썬 패키징 프로세스를 개발자의 영역과 사용자의 영역으로 구분하게 되었다는 점이다.

프로세스가 빌드, 업로드, 다운로드, 설치의 단계일때 개발자가 수행하는 빌드, 업로드는 setuptools, 사용자가 수행하는 다운로드, 설치는 easy_install이 수행하도록 도구의 역할을 나누게 된 것이다.

 

4. pip 개선된 패키지 설치도구

2008년 파이썬하면 빼놓을 수 없는 pip가 등장하게 된다.

pip은 easy_install을 대체하기 위해 만들어졌다. easy_install은 패키지를 설치하는 기능에는 충실하지만 설치된 패키지를 삭제하거나 설치된 패키지들의 목록을 보여주는 기능등이 없어 패키지 관리 도구로서의 제한적인 불편함이 있었다.

pip은 파이썬 패키지를 설치하고 관리하는 데에 특화된 도구로서, easy_install이 가지고 있던 패키지 관리 측면의 문제들을 해결하면서 git 레포지토리에서 파이썬 패키지를 바로 설치할 수 있게 하는 등의 몇 가지 부가 기능을 함께 제공했다.

당연하게도 pip은 발표되고 얼마 지나지 않아 easy_install의 역할을 완벽히 대체했고, 2013년 PEP453를 통해 파이썬 3.4부터 파이썬의 디폴트 패키지 인스톨러가 되었다.

 

5. setuptools와 setup.py의 문제

굉장히 잘 작동하고 있는 것처럼 보이지만 해결할 수 없는 근본적인 문제 몇 가지를 가지고 있다.

대표적인 문제로는 setup.py 파일이 setuptools에 의존적이라는 점이다.

setuptools는 파이썬의 표준 라이브러리가 아니다! 이는 의도적인 것으로 사람들이 얼마든지 새로운 패키지 빌드 시스템을 만들 수 있고 그렇게 하는 것이 권장되고 있다.

의존적 문제의 예시를 들어보자

1. 새로 만든 패키지를 빌드하기 위해 setuptools A 버전에서 지원하는 특수한 기능이 요구된다.
2. setup.py에 적어둔다.
3. 그런데 setup.py를 파싱하기 위해서는 시스템에 setuptools가 설치되어 있어야한다.
4. 시스템에 설치된 setuptools의 버전이 A가 아니라 B라면?

 

6. pyproject.toml의 등장

이제 처음에 찾아보려 했던 pyproject.toml이 등장한다.

setup.py에 근본적인 문제의 원인은 메타데이터를 저장하는 파일이 그 자체로 특정한 빌드시스템(setuptools)에 종속되기 때문이다.

이 문제를 해결하기 위한 방법은 특정 빌드 시스템에 종속되지 않는 선언적인 설정 파일을 사용하는 것이다.

이를 위해 2016년에 pyproject.toml가 탄생한다.

이 파일의 역할은 단순하다. TOML 포맷으로 만들어진 설정파일이며 파이썬 패키지를 어떻게 빌드하는지 어떤 빌드 시스템을 사용해야하는지를 명시하는 것이다. 물론 setuptools를 빌드 시스템으로 사용하는것도 가능하다.

[build-system]
requires = ["setuptools>=42", "wheel"]


[build-system]
requires = ["flit_core >=2, <4"]
build-backend = "flit_core.buildapi"

pyproject.toml은 원래 위의 예시처럼 패키지 빌드와 관련된 정보만을 담기 위한 파일로 탄생했다.

그러나 패키지 개발자들은 개발과 관련된 설정 값을 관리하는 용도로도 pyproject.toml을 유용하게 사용할 수 있음을 발견했다.

그러면서 빌드 전에 수행되어야하는 테스트, 코드 포맷팅 등의 정보를 pyproject.toml에 적어두기 시작했다.

대표적으로 포맷팅 도구인 black 테스트 프레임워크 pytest 등이 pyproject.toml에 값을 저장하고 있다.