PEP 439 – Python 설치에 암묵적 pip 부트스트랩 포함
- Author:
- Richard Jones <richard at python.org>
- BDFL-Delegate:
- Alyssa Coghlan <ncoghlan at gmail.com>
- Discussions-To:
- Distutils-SIG list
- Status:
- Rejected
- Type:
- Standards Track
- Topic:
- Packaging
- Created:
- 18-Mar-2013
- Python-Version:
- 3.4
- Post-History:
- 19-Mar-2013
- Resolution:
- Distutils-SIG message
번역·라이선스 안내
이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판
초록
이 PEP는 Python 사용자가 서드파티 모듈을 더 쉽게 사용할 수 있도록 Python 설치에 pip 부트스트랩 실행 파일을 포함할 것을 제안합니다.
이 PEP는 pip 구현을 Python 표준 라이브러리에 포함하자고 제안하지 않습니다. 또한 PEP 427(“The Wheel Binary Package Format 1.0”)과 TODO distlib PEP가 제공하는 것 이상의 패키지 관리나 설치 메커니즘을 구현하자고 제안하지도 않습니다.
PEP 거부
이 PEP는 같은 최종 결과를 더 신뢰할 수 있는 방식으로 달성할 수 있는 더 명시적인 메커니즘이 채택되면서 거부되었습니다. 더 명시적인 부트스트래핑 메커니즘은 PEP 453에 설명되어 있습니다.
근거
현재 서드파티 Python 모듈을 설치하는 사용자 경험은 충분히 단순하지 않습니다. 모든 서드파티 모듈이 설치 프로그램을 설치하는 방법을 사용자에게 알려야 하며, 보통은 설치 프로그램으로 가는 링크를 제공하는 방식으로 알립니다. 그 링크가 오래되었을 수도 있고, 설치 프로그램을 설치하는 데 필요한 단계가 사용자가 더 나아가지 못할 만큼 큰 장애물이 될 수도 있습니다.
낮은 진입 장벽을 중시하는 대규모 Python 프로젝트들은 새 사용자에게 이러한 걸림돌이 생길 수 있다는 이유로 서드파티 패키지에 의존하기를 꺼려 왔습니다.
표준 Python 설치에 패키지 설치 프로그램 명령이 포함되면 추가 소프트웨어를 설치하는 데 따르는 장벽이 상당히 낮아집니다. 따라서 이를 통해 Python 프로젝트가 서드파티 소프트웨어를 재사용할 가능성이 높아지기를 기대합니다.
Python 커뮤니티에는 현재 pip와 setuptools의 부트스트랩 절차가 복잡하다는 문제도 있습니다. 이들은 모두 사용법이 조금씩 다른 자체 부트스트랩 다운로드 파일을 가지고 있으며, 경우에 따라서는 서로를 참조하기까지 합니다. 이들 모두에 공통되며 사용법이 단순한 단일 부트스트랩이 있다면 훨씬 바람직할 것입니다.
또한 이를 통해 Python 표준 라이브러리에 점점 더 많은 소프트웨어를 포함하자는 제안이 줄어들고, 그 결과 널리 쓰이는 Python 소프트웨어를 Python 설치를 업그레이드하지 않고도 더 쉽게 업그레이드할 수 있게 되기를 기대합니다.
제안
부트스트랩은 PyPI에서 pip 구현과 setuptools의 설치 파일을 내려받아 이들을 설치합니다.
이 제안은 패키징의 두 가지 구성 요소에 영향을 미칩니다. 하나는 The pip bootstrap이고, 다른 하나는 패키지 설치가 쉬워진 덕분에 생기는 Modifications to publishing packages입니다.
이 제안의 핵심은 사용자가 pip를 직접 설치하지 않고도 pip를 사용할 수 있어야 한다는 것입니다.
pip 부트스트랩
Python 설치에는 pip 기능을 임포트하려고 시도하는 “pip3”라는 실행 파일이 포함됩니다(이름을 정한 근거 등은 PEP 394를 참조하십시오). 임포트할 수 있으면 pip 명령이 평소처럼 진행됩니다. 임포트할 수 없으면 pip 구현과 setuptools wheel 파일을 내려받아 pip를 부트스트랩합니다. 이하에서 “pip 구현”의 설치는 setuptools와 virtualenv의 설치를 포함하는 것으로 간주합니다. 설치가 끝나면 pip 명령이 평소처럼 진행됩니다. 부트스트랩 과정이 완료되면 “pip3” 명령은 더 이상 부트스트랩이 아니라 완전한 pip 명령이 됩니다.
완전한 pip 코드 대신 부트스트랩을 사용하는 이유는 pip를 번들로 포함할 필요가 없도록 하고, pip를 정규 Python 업그레이드 일정 및 절차와 별개로 업그레이드할 수 있도록 하기 위해서입니다.
sudo 관련 문제를 피하기 위해, 부트스트랩은 기본적으로 pip 구현을 PEP 370에서 정의되고 Python 2.6/3.0에서 구현된 사용자별 site-packages(사이트 패키지) 디렉터리에 설치하도록 하겠습니다. 시스템 Python에 설치하지 않으므로 (예를 들어 Linux 시스템에서) 다른 패키징 시스템과 충돌하는 일도 피할 수 있습니다. 사용자가 PEP 405 가상 환경 안에 있다면 pip 구현은 그 가상 환경에 설치됩니다.
부트스트랩 과정은 다음과 같이 진행됩니다:
- 사용자 시스템에 Python(3.4 이상)이 설치되어 있습니다. Python 설치 경로의 “scripts” 디렉터리에는 “pip3”라는 부트스트랩 스크립트가 있습니다.
- 사용자는 pip 명령을 실행합니다. 보통 “pip3 install <package>” 형태이며, 예를 들면 “pip3 install Django”입니다.
- 부트스트랩 스크립트는 pip 구현을 임포트하려고 시도합니다. 임포트에 성공하면 pip 명령은 평소처럼 처리됩니다. 여기서 끝납니다.
- pip 구현을 임포트하지 못하면 부트스트랩은 사용자에게 “pip을 설치”해야 한다고 알립니다. 부트스트랩은 pip을 시스템 전체 site-packages로 설치할지, 사용자 전용 패키지로 설치할지 사용자에게 묻습니다. 비대화식으로도 사용할 수 있도록 이 선택지는 pip의 명령줄 옵션으로도 제공됩니다.
- 부트스트랩은 PyPI에 접속하여 최신 다운로드 wheel 파일을 가져옵니다(PEP 427 참조).
- 파일을 다운로드하면 “python setup.py install”을 사용하여 설치합니다.
- 이제 pip 도구는 pip 구현을 임포트할 수 있으며, 사용자가 요청한 명령을 평소처럼 계속 처리합니다.
사용자가 공용 인터넷에 접근할 수 없는 환경에서 로컬 패키지 저장소에만 의존하고 있을 수도 있습니다. 이러한 사용자는 “pip3 install” 명령에 “-i”(Python 패키지 색인의 기본 URL) 인자를 사용하면 됩니다. 이 인자는 PyPI를 가리키는 기본 색인 URL을 재정의할 뿐입니다.
일부 사용자는 pip 구현 파일을 받아 올 수 있을 만한 인터넷 접속 환경이 없을 수도 있습니다. 이러한 사용자는 setuptools와 pip의 tar 파일을 직접 다운로드하여 설치할 수 있습니다. 이 사용 사례를 위한 별도의 지원은 추가할 필요가 없습니다.
pip 구현 설치 파일은 안전하게 다운로드됩니다. pypi.python.org로부터의 전송은 HTTPS로 이루어지며 CA 인증서 검사를 거칩니다. 이 기능은 운영 체제 인증서를 사용하여 Python 3.4 이상에서 제공됩니다(PEP XXXX를 참조하십시오).
색인 위치와 다운로드 옵션을 제어하는 이러한 인자 외에도, “pip3” 부트스트랩 명령은 출력 상세도, 출력 억제, 로깅을 위한 표준 pip 옵션을 추가로 지원할 수 있습니다.
“pip3” 명령은 부트스트랩 과정에서 사용되고 그 밖의 경우에는 무시되는 두 가지 새 명령줄 옵션을 지원합니다. 이 옵션들은 pip 구현이 설치될 위치를 제어합니다:
--bootstrap- 사용자의 패키지 디렉터리에 설치합니다. 이 옵션의 이름은 이 옵션을 권장 설치 옵션으로 내세우기 위해 정한 것입니다.
--bootstrap-to-system- 시스템 site-packages(사이트 패키지) 디렉터리에 설치합니다.
이 명령줄 옵션들도 pip 구현에서 구현되어야 하지만, 그 외에는 무시됩니다.
pip이 사용자 패키지 디렉터리에 설치되어 있다면 pip이 기본적으로 해당 위치에 패키지를 설치하도록 하는 방안을 고려해야 합니다.
“pip3” 명령의 “–no-install” 옵션은 부트스트래핑 과정에 영향을 주지 않습니다.
패키지 게시 방식의 변경
PyPI에 패키지를 게시하는 도구가 될 새로운 Python 패키지 “pypublish”를 추가로 제안합니다. 이 패키지는 현재의 “python setup.py register” 및 “python setup.py upload” distutils 명령을 대체합니다. 이번에도 신중하게 진행되는 Python 릴리스 주기와 광범위하게 존재하는 기존 Python 설치 때문에, 이 명령들은 버그 수정과 확장이 어렵습니다. 또한 “register” 및 “upload” 명령을 인증서 검증을 거치는 HTTPS를 통해 수행할 수 있어야 합니다. Python과 함께 CA 인증서 키체인을 배포하는 것은 현실적으로 실현하기 어려우므로(키체인을 갱신하는 일은 관리하기가 상당히 어렵습니다), 이 명령들과 이에 딸린 키체인을 Python 자체와는 별도로 설치하고 업그레이드할 수 있게 하는 것이 바람직합니다.
패키지 등록 및 업로드를 위한 기존 distutils 메커니즘은 유지되지만, 폐지 예정 경고가 표시됩니다.
구현
이 PEP에서 요구하는 pip의 변경 사항은 해당 프로젝트의 이슈 트래커 [2]에서 추적되고 있습니다. 가장 주목할 만한 것은 pip 명령줄에 –bootstrap과 –bootstrap-to-system을 추가하는 것입니다.
pip과 setuptools 프로젝트가 wheel 형식의 다운로드를 배포하는 것이 바람직합니다.
이 구현에 필요한 코드는 위에서 설명한 “pip3” 명령입니다. 추가되는 pypublish는 이 PEP 작업 범위 밖에서 개발할 수 있습니다.
마지막으로, “pip3”를 Python 2.6 이상으로 포팅하여 이 단일 명령이 기존의 pip, setuptools, virtualenv(부트스트랩에 추가될 예정입니다) 부트스트랩 스크립트를 대체할 수 있게 하는 것이 바람직합니다. 향후 Python 2.7 릴리스에 이 부트스트랩을 포함하는 것 또한 매우 바람직합니다.
위험 요소
pip 구현 다운로드에 서명하는 데 사용되는 키가 유출될 수 있으며, 현재 이 PEP는 키 폐기를 위한 메커니즘을 제안하지 않습니다.
이름이 똑같이 “pip”인 Perl 패키지 설치 프로그램이 있습니다. 이 도구는 상당히 드물며 흔히 사용되지 않습니다. Linux 배포판인 Fedora는 역사적으로 Python의 “pip”을 “python-pip”으로, Perl의 “pip”을 “perl-pip”으로 명명해 왔습니다. 이 정책은 변경되어[3] 앞으로 새로 설치되거나 업그레이드되는 Fedora에서는 Python의 “pip”에 “pip”이라는 이름을 사용합니다. 기존의(업그레이드되지 않은) 설치본에서는 Python “pip”이 여전히 예전 이름을 사용하지만, 혼동의 가능성은 이제 크게 줄었습니다.
참고 문헌
감사의 글
제안에 대한 의견을 주고 Red Hat 문제를 처리해 준 Alyssa Coghlan에게 감사드립니다.
의견을 준 Jannis Leidel과 Carl Meyer에게 감사드립니다. 피드백을 준 Marcus Smith에게 감사드립니다.
Fedora 문제를 해결해 주신 Marcela Mašláňová에게 감사드립니다.
Copyright
This document has been placed in the public domain.