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

Table of Contents

초록
PEP 거부
근거
제안
- pip 부트스트랩
- 패키지 게시 방식의 수정
구현
위험 요소
참고 문헌
감사의 말
Copyright

번역·라이선스 안내

이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판

초록

이 PEP는 Python 사용자가 타사 모듈을 쉽게 사용할 수 있도록 Python 설치에 pip 부트스트랩 실행 파일을 포함할 것을 제안합니다.

이 PEP는 Python 표준 라이브러리에 pip 구현을 포함할 것을 제안하지 않습니다. 또한 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 설치에는 “pip3”이라는 실행 파일이 포함되며(PEP 394에는 명명 근거 등이 설명되어 있습니다), 이 파일은 pip 기능을 가져오려고 시도합니다. 가져올 수 있으면 pip 명령이 평소와 같이 진행됩니다. 가져올 수 없으면 pip 구현과 setuptools 휠 파일을 다운로드하여 pip를 부트스트랩합니다. 이후 “pip 구현”의 설치에는 setuptools 및 virtualenv의 설치도 포함되는 것으로 간주합니다. 설치가 완료되면 pip 명령이 평소와 같이 진행됩니다. 부트스트랩 프로세스가 완료되면 “pip3” 명령은 더 이상 부트스트랩이 아니라 완전한 pip 명령이 됩니다.

pip를 함께 번들로 제공할 필요가 없고, pip를 일반적인 Python 업그레이드 기간 및 절차와 무관하게 업그레이드할 수 있도록 전체 pip 코드 대신 부트스트랩을 사용합니다.

sudo 문제를 피하기 위해 부트스트랩은 PEP 370에 정의되어 있고 Python 2.6/3.0에서 구현된 사용자별 site-packages 디렉터리에 pip 구현을 설치하도록 기본 설정합니다. 시스템 Python에 설치하지 않으므로 다른 패키징 시스템과 충돌하는 일도 피할 수 있습니다(예를 들어 Linux 시스템에서 그렇습니다). 사용자가 PEP 405 가상 환경 안에 있다면 pip 구현은 해당 가상 환경에 설치됩니다.

부트스트랩 프로세스는 다음과 같이 진행됩니다.

사용자 시스템에 Python(3.4 이상)이 설치되어 있습니다. Python 설치의 “scripts” 디렉터리에 “pip3”이라는 부트스트랩 스크립트가 있습니다.
사용자는 일반적으로 “pip3 install <package>”와 같은 pip 명령을 호출하며, 예를 들면 “pip3 install Django”와 같습니다.
부트스트랩 스크립트는 pip 구현을 가져오려고 시도합니다. 성공하면 pip 명령이 정상적으로 처리됩니다. 중지하십시오.
pip 구현을 가져오지 못하면 부트스트랩은 사용자에게 “install pip”가 필요하다고 알립니다. 부트스트랩은 pip를 시스템 전체의 site-packages로 설치할지, 사용자 전용 패키지로 설치할지 사용자에게 묻습니다. 비대화형 사용이 가능하도록 이 선택 사항은 pip의 명령줄 옵션으로도 제공됩니다.
부트스트랩은 최신 다운로드 휠 파일을 얻기 위해 PyPI에 접속합니다(PEP 427을 참조하십시오).
파일을 다운로드하면 “python setup.py install”을 사용하여 설치합니다.
이제 pip 도구는 pip 구현을 가져와 요청된 사용자 명령을 정상적으로 계속 처리할 수 있습니다.

사용자는 공용 인터넷에 액세스할 수 없고 로컬 패키지 저장소에만 의존하는 환경에서 실행 중일 수 있습니다. 이들은 “pip3 install” 명령에 “-i”(파이썬 패키지 색인의 기본 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” 옵션은 부트스트래핑 과정에 영향을 미치지 않습니다.

패키지 게시 방식의 수정

“pypublish”라는 새로운 Python 패키지가 추가로 제안되며, 이는 PyPI에 패키지를 게시하기 위한 도구가 될 것입니다. 이는 기존의 “python setup.py register” 및 “python setup.py upload” distutils 명령을 대체하게 됩니다. 다시 말하지만, 신중한 Python 릴리스 주기와 광범위하게 존재하는 기존 Python 설치본들로 인해 이 명령들은 버그를 수정하고 확장하기가 어렵습니다. 또한 “register”와 “upload” 명령이 인증서 검증을 거치는 HTTPS를 통해 수행될 수 있어야 한다는 요구가 있습니다. CA 인증서 키체인을 Python과 함께 배포하는 것은 사실상 실현 가능하지 않으므로(키체인 갱신은 관리하기가 상당히 어렵습니다), 해당 명령들과 이에 딸린 키체인을 Python 자체와는 별도로 설치·업그레이드할 수 있게 만드는 것이 바람직합니다.

패키지 등록 및 업로드를 위한 기존 distutils 메커니즘은 폐지 경고와 함께 유지됩니다.

구현

이 PEP에서 요구하는 pip에 대한 변경 사항은 해당 프로젝트의 이슈 트래커 [2]에서 추적되고 있습니다. 가장 주목할 만한 것은 pip 명령줄에 –bootstrap과 –bootstrap-to-system이 추가된다는 점입니다.

pip와 setuptools 프로젝트가 wheel 형식의 다운로드를 배포하는 것이 바람직할 것입니다.

이 구현을 위해 필요한 코드는 위에서 설명한 “pip3” 명령입니다. 추가적인 pypublish는 이 PEP 작업의 범위 밖에서 개발될 수 있습니다.

마지막으로, 단일 명령이 기존의 pip, setuptools, virtualenv(부트스트랩에 추가될 예정) 부트스트랩 스크립트를 대체할 수 있도록 “pip3”가 Python 2.6+로 이식되는 것이 바람직할 것입니다. 해당 부트스트랩이 향후 Python 2.7 릴리스에 포함되는 것 또한 매우 바람직할 것입니다.

위험 요소

pip 구현 다운로드에 서명하는 데 사용되는 키가 침해될 수 있으며, 이 PEP는 현재 키 폐기(key revocation) 메커니즘을 제안하지 않습니다.

“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.