나만의 python 패키지 만들기 - (1) 우리는 python에서 어떻게 다른 사람의 코드를 사용할 수 있을까

1. 개요:

python으로 코드를 작성한 지 10년이 넘으면서, 다른 사람이 작성해 둔 코드를 pip를 통해서 편하게 설치를 했다. 이슈를 만날 때마다 패키지 시스템을 부분적으로 공부를 하게 되었지만, python package를 만들기로 마음먹은 지금 한번 python package 시스템의 역사를 정리하여 내 궁금증을 풀어보려고 합니다.

 

2. 궁금한 점들:

python package를 사용하면서 다양한 키워드들과 파일들을 마주하게 되는데 그런 것 중에 명확히 답변하기 어려운 것들을 정리해 보았다.

• pypi가 뭐지?
• pip vs setuptools: pip로 설치할 때 setup.py를 실행한다하기도 하고.. virtualenv를 깔면 setuptools는 깔려있는데 이건 어떤 역할이지?
• egg vs whl: pip를 설치할 때 어떤건 .egg파일을 받는 것 같고, 어떤건 .whl파일을 받고.. 어떤건 .whl파일이 없다고 만든다고 하는데 이건 왜그런거지?
• pyproject.toml vs setup.py: 예전에는 설치 관련해서 setup.py를 쓰라고 했는데, 요새는 pyproject.toml에 설치파일도 관리하고.. 어떻게 하는 게 좋은 거지?

3. Python packaging system과 관련된 역사

처음부터 공부하기는 어려우니 2019년 pycon 영상과, 최근거는 chatgpt를 사용해서 정보를 정리해보았다.

 

https://www.youtube.com/watch?v=s5lJsFzv_iI

 

1. Python 1.0과 초기의 코드 공유: 1994년 Python 1.0이 처음 발표됐을 때, 코드를 공유하는 공식적인 방법은 없었습니다. 개발자들은 자신의 웹사이트에 코드를 호스팅하고, 다른 사람들이 그 코드를 찾아서 직접 세팅하여 사용해야 했습니다.
2. distutil의 등장: 2000년에 Python 2.0이 나오면서 distutil이 소개되었습니다. 이를 통해 Python 1.6과 2.0에서 코드를 공유할 수 있는 표준 방법이 제공되기 시작했습니다.
3. PyPI의 탄생: 2003년에는 PyPI(Python Package Index)가 등장했습니다. PyPI는 패키지를 등록할 수 있는 인덱스로, 초기에는 코드를 직접 호스팅한 후 그 링크를 PyPI에 등록하는 방식이었습니다. 그러나 2005년에는 PyPI 자체의 호스팅 기능이 추가되었습니다.
4. setuptools와 .egg 포맷: 2004년에는 setuptools가 등장했습니다. 이는 distutil 위에 구축된 도구로, easy_install을 통해 PyPI에 등록된 패키지를 쉽게 설치할 수 있게 되었습니다. 또한, .egg 패키지 포맷이 등장하여 precompiled된 binary extension을 지원하게 되었습니다. 그러나 .egg는 몇 가지 문제점을 가지고 있었습니다.
5. virtualenv와 pip의 등장: 2007년에는 virtualenv가, 그 다음해인 2008년에는 pip가 소개되었습니다. setuptools에는 패키지를 쉽게 설치할 수 있지만 제거하는 기능이 없었는데, pip는 이를 해결해주었습니다.
6. setup.py의 문제점: setup.py는 여러 문제점을 가지고 있었습니다. 사용자가 제어할 수 없는 동작을 수행하거나, 완전히 제거되지 않는 라이브러리 문제, 설치 속도의 느림 등이 있었습니다.
7. Wheel 패키지 형식의 등장(2013년):  Wheel은 파이썬의 새로운 바이너리 패키지 형식으로, 패키지를 더 빠르게 설치할 수 있게 해줍니다. Wheel은 미리 빌드된 바이너리 패키지를 제공하여 C 컴파일러가 필요 없이 패키지를 설치할 수 있게 해줍니다.
8. PEP 517과 518 (2015): 이 두 PEP는 파이썬 패키징의 기본을 현대화하는 데 중요한 역할을 합니다. PEP 518은 pyproject.toml 파일을 도입하여 빌드에 필요한 종속성을 명시합니다. PEP 517은 새로운 빌드 백엔드를 정의하여 setup.py에 대한 의존성을 줄입니다.
9. Flit: Flit은 PEP 517 및 518을 지원하는 패키징 도구 중 하나입니다. Flit은 간단한 패키지에 적합하며, 복잡한 빌드나 C 확장을 필요로 하지 않습니다.
10. Poetry: Poetry는 의존성 관리와 패키징을 위한 도구로, pyproject.toml을 사용하여 프로젝트의 설정과 의존성을 관리합니다. Poetry는 또한 PEP 517 및 518을 지원합니다.
11. Enscons: Enscons는 scons 빌드 시스템을 기반으로 한 PEP 517 백엔드입니다. 복잡한 패키징 요구 사항, 예를 들면 C 확장과 같은 것들을 처리하기 위해 설계되었습니다.
12. 패키징 도구의 진화: 새로운 패키징 도구와 표준들은 파이썬 패키징을 더욱 간단하고 일관성 있게 만들기 위해 도입되었습니다. 그러나 파이썬의 오랜 역사와 다양한 패키징 요구 사항으로 인해, 이러한 변화는 점진적으로 이루어지고 있습니다.

4. 궁금한 점들 답변하기:

• pypi가 뭐지? 파이썬 패키지 인덱스(PyPI)는 Python 패키지를 등록하고 공유하기 위한 온라인 공간이다. 여기에는 수천 개의 Python 패키지가 등록되어 있어, 우리가 편하게 설치를 할 수 있게 검색하도 다운로드하여 쓸 수 있게 도와준다.
• pip vs setuptools: pip와 setuptools는 역할이 다른데. pip는 패키지를 설치하는 도구고, setuptools는 패키지를 빌드하거나 배포할 때 사용하는 툴이다. 지금은 더 다양한 설치도구(poetry)나 빌드(flit), 배포도구(poetry)가 존재한다.
• egg vs whl: .whl파일은 .egg파일을 대체하는 새로운 형식으로. 몇가지 개선사항이 있습니다.
  1. .whl파일은 표준 스펙 사항이 존재합니다. (naming convention을 통해서 적합한 python 버젼을 선택해서 설치하는 등의 장점이 존재합니다.) 
  2. .whl파일은 distribution format의 기능만 하지만, .egg는 배포와, runtime installation을 지원합니다. (runtime installation의 경우에는 의도하지 않은 side effect를 낳을 수 있어서 선호하지 않습니다.)
  3. 이제 .egg파일 포맷으로 pypi에 올리는건 불가능해졌습니다.
• pyproject.toml vs setup.py:  pyproject.toml이 setup.py를 대체하는 새로운 파이썬 프로젝트의 환경 설정과 관련된 파일입니다. pyproject.toml은 더 현대적이고 표준화된 형식으로 프로젝트 정보를 관리하며, 요새는 여기에 빌드와 관련된 정보를 저장할 수 있습니다.

5. Python 패키지 생태계의 미래:

공부를 계속 하다보니, python package 생태계는 계속 발전한다는게 느껴졌다. 현재는 커뮤니티의 확장성을 믿고 다양한 빌드, 배포 패키지가 나오는 것을 기대하고 있는 것 같다. 조금씩 발전하고 있는데, 몇년 뒤에는 어떻게 바뀌어 있을지 궁금하다.

---

가볍게 python package의 역사를 알아봤는데, 이제는 실제로 python package에 내가 원하는 코드를 올려서 배포하는 작업을 해봐야 할 것 같다. 궁금한게 있다면 댓글로 알려주세요!