Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python 개선 제안 한국어 번역

PEP 453 – Python 설치에서 pip의 명시적 부트스트래핑

Author:
Donald Stufft <donald at stufft.io>, Alyssa Coghlan <ncoghlan at gmail.com>
BDFL-Delegate:
Martin von Löwis
Status:
Final
Type:
Standards Track
Created:
10-Aug-2013
Post-History:
30-Aug-2013, 15-Sep-2013, 18-Sep-2013, 19-Sep-2013, 23-Sep-2013, 29-Sep-2013, 13-Oct-2013, 20-Oct-2013
Resolution:
Python-Dev message
Table of Contents

번역·라이선스 안내

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

초록

이 PEP는 Python 2.7, 3.3, 3.4의 Installing Python Modules 안내서를 갱신하여 Python 패키지의 기본 설치 프로그램으로 pip 사용을 공식적으로 권장하고, 이 권장을 뒷받침하기 위해 Python 3.4에서 pip를 기본으로 제공하도록 적절한 기술적 변경을 할 것을 제안합니다.

PEP 수락

이 PEP는 2013년 10월 22일 화요일에 Martin von Löwis에 의해 Python 3.4에 포함되도록 승인되었습니다.

이 PEP의 구현을 추적하기 위해 Issue 19347이 생성되었습니다.

근거

이 PEP의 제안에는 서로 관련되어 있지만 구별되는 두 가지 근거가 있습니다. 첫 번째는 새 사용자의 경험과 관련되고, 두 번째는 더 넓은 Python 패키징 생태계의 발전을 더 잘 가능하게 하는 것과 관련됩니다.

신규 사용자 경험 개선

현재 플랫폼 패키지 관리자와 저장소가 없는 시스템에서는 새로 설치한 Python에 서드파티 Python 패키지를 설치하려면 먼저 적절한 패키지 관리자를 찾아낸 다음 그것을 설치해야 합니다.

플랫폼 패키지 관리자를 실제로 갖춘 시스템에서도 Python 패키지 색인(Python Package Index)에 있는 모든 Python 패키지가 포함되어 있을 가능성은 낮으며, 원하는 서드파티 패키지가 있더라도 플랫폼 패키지 관리자에서의 정확한 이름이 무엇인지 분명하지 않을 수 있습니다.

이는 Python 패키지 색인(Python Package Index) 생태계에서 Python 패키지를 효과적으로 다루려면 사용자가 어떤 패키지 관리자를 설치해야 하는지, 그것을 어디에서 구할 수 있는지, 그리고 어떻게 설치하는지를 알아야 한다는 뜻입니다. 그 결과, 현재 서드파티 Python 프로젝트는 바람직하지 않은 여러 대안 중에서 하나를 선택해야 합니다.

  • 사용자가 적절한 크로스 플랫폼 패키지 관리자를 이미 설치했다고 가정합니다.
  • 설치 지침을 중복해서 싣고 사용자에게 패키지 관리자를 설치하는 방법을 알려 줍니다.
  • 사용자의 설치 부담을 덜기 위해 의존성 사용을 완전히 포기합니다.

이 선택지들에는 모두 상당한 단점이 있습니다.

프로젝트가 사용자에게 도구가 이미 있다고 단순히 가정하면, 설치 명령이 동작하지 않을 때 초보 사용자는 혼란스러운 오류 메시지를 받을 수 있습니다. 일부 운영 체제는 존재하지 않는 명령을 찾아 그 명령이 동작하도록 설치할 수 있는 OS 패키지를 제안하는 전역 훅을 제공하여 이러한 불편을 덜어 줄 수 있지만, 이는 해당 크로스 플랫폼 설치 프로그램 명령을 제공하는 패키지를 포함한 플랫폼 패키지 관리자가 있는 시스템(여러 주요 Linux 배포판 등)에서만 동작합니다. Windows와 Mac OS X 사용자, 또는 더 보수적인 Linux 배포판에서는 이러한 도움을 받을 수 없습니다. 초보자(프로그래밍, 명령줄 도구 사용, 시스템 환경 변수 편집을 모두 처음 접하는 경우가 많습니다)가 이 문제를 다루면서 겪는 어려움은 전문 교육자와 새 사용자에게 Python을 소개하는 다른 사람들로부터 Python 코어 개발자가 정기적으로 받는 피드백의 단골 주제입니다.

프로젝트가 설치 지침을 중복해서 싣기로 할 수도 있습니다. 즉 자기 프로젝트의 설치 방법을 알려 주기 전에 사용자에게 패키지 관리자 설치 방법부터 알려 주는 것입니다. 그러면 이 지침을 갱신해야 할 때마다 그것을 중복해서 실은 모든 프로젝트가 저마다 갱신해야 합니다. 이는 서로 경쟁하는 설치 도구가 여러 개 있고 프로젝트마다 서로 다른 도구를 권장할 때 특히 문제가 됩니다.

이 특정 문제는 pip를 기본 설치 프로그램으로 강력하게 홍보하고, 다른 프로젝트가 pip 자체의 부트스트래핑 안내를 복제하는 대신 참조하도록 권장함으로써 부분적으로 완화할 수 있습니다. 그러나 이 방식이 만드는 사용자 경험은 여전히 그다지 좋지 않습니다(다만 pip와 그 의존성을 위한 통합 Windows 설치 프로그램을 만드는 작업이 진행 중이므로 해당 플랫폼의 상황은 나아질 것입니다. 또 Mac OS X와 *nix 플랫폼에는 일반적으로 wget이 있으므로 명령줄에서 부트스트랩 스크립트를 쉽게 내려받아 실행할 수 있습니다).

의존성을 아예 포기하기로 한 프로젝트에는 두 가지 방법밖에 없습니다. 문제마다 자체 해결책을 고안하여 다른 프로젝트가 이미 한 일을 되풀이하거나, 다른 프로젝트를 자기 소스 트리에 그대로 포함해야 합니다. 두 선택지 모두 나름의 문제를 안고 있습니다. 생태계 전반에서 유지 보수 작업이 중복될 수 있습니다. 또 업스트림이 새 버전을 릴리스해도 포함된 코드나 중복된 작업이 자동으로 갱신되지 않으므로 사용자가 보안 문제에 취약해질 수도 있습니다.

특정 크로스 플랫폼 패키지 관리자를 공식적으로 권장하고 기본으로 제공하면 이러한 서드파티 패키지를 설치하려는 사용자가 더 쉽게 설치할 수 있습니다. 패키지를 배포하는 사람들의 일도 쉬워집니다. 대부분의 사용자에게 적절한 설치 도구가 있다고(또는 그것을 얻는 방법을 다룬 명확한 지침을 볼 수 있다고) 안심하고 가정할 수 있기 때문입니다. Wheel 패키지 형식은 (의도적으로) setup.py 형태의 내장 “설치 프로그램”을 갖고 있지 않으므로 wheel 파일로부터 설치하려는 사용자는 가장 단순한 경우에도 설치 프로그램이 필요하게 되며, 따라서 이는 앞으로 더 중요해질 것으로 예상됩니다.

서드파티 패키지를 실제로 설치하는 부담을 줄이면 유용한 모듈을 모두 표준 라이브러리에 추가하라는 압력도 줄어들 것입니다. 이를 통해 표준 라이브러리에 무언가를 추가할 때, 서드파티 패키지 설치의 전반적인 어려움을 포함의 근거로 삼는 대신, Python이 왜 특정 도구를 기본으로 갖추어야 하는지, 그리고 그 패키지가 표준 라이브러리의 18-24개월 기능 릴리스 주기를 따르는 것이 왜 합당한지에 더 집중할 수 있습니다.

표준 설치 시스템을 제공하는 것은 zc.buildout, hashdist, conda와 같은 대안 빌드 시스템 및 설치 프로그램 시스템을 부트스트래핑하는 데에도 도움이 됩니다. pip install <tool>이 동작하는 한, 표준 Python 전용 설치 프로그램은 이러한 유틸리티에 접근할 수 있는 상당히 안전한 크로스 플랫폼 메커니즘을 제공합니다.

더 넓은 Python 패키징 생태계의 발전을 가능하게 하기

(대부분의 언어 기능처럼 단지 미래 버전만이 아니라) 현재 널리 사용되는 Python 버전을 포괄하는 전환 전략 없이는 어떤 새 패키징 표준도 널리 채택될 수 없으므로, 이 PEP에서 제안하는 변경은 Python 패키징 생태계의 발전에 필요한 단계로 간주됩니다

더 넓은 커뮤니티는 Python 패키지 색인(Python Package Index)을 Python 소프트웨어와 Python 패키지를 배포하고 설치하는 수단으로 받아들였지만, 언어의 발전과 안전한 소프트웨어 배포는 서로 관심사가 다르기 때문에 후자를 제대로 지원하려면 이전 버전까지 아우르는 더 빠른 기능 릴리스 주기가 필요합니다.

게다가 CPython 핵심 개발 팀은 나머지 커뮤니티보다 훨씬 앞서 이전 파이썬 버전의 지원을 중단할 수 있는 여유가 있습니다. 다운스트림 상용 재배포자들이 여전히 그 버전을 필요로 하는 사용자에게 지원을 제공하는 일을 맡고, 많은 서드파티 라이브러리가 그 버전들이 널리 사용되는 동안에는 호환성을 유지하기 때문입니다.

이는 현재의 setup.py install 기반 패키지 설치 모델이 새로운 패키징 표준의 개발과 채택에 심각한 어려움을 준다는 뜻입니다. 프로젝트가 setup.py 파일을 어떻게 작성하느냐에 따라, 설치 명령(및 기타 작업)이 결국 표준 라이브러리의 distutils 패키지를 호출하게 될 수 있기 때문입니다.

이것이 더 넓은 생태계에 어떤 문제를 일으킬 수 있는지 보여 주는 지표로, Python 2.6의 distutils 기능 집합은 2008년 6월에(Python 2.6b1 릴리스와 함께) 동결된 반면, Python 2.7의 distutils 기능 집합은 2010년 4월에(Python 2.7b1 릴리스와 함께) 동결되었다는 점을 생각해 보십시오.

반면에 pip 같은 별도의 설치 프로그램 애플리케이션(distutils를 직접 호출하는 setup.py 파일도 새 패키징 표준을 지원하도록 보장합니다)을 사용하면, (대략 6개월마다 새 기능 릴리스가 나오는) pip를 업그레이드하는 것만으로 이전 버전의 Python에서도 새 패키징 표준을 지원할 수 있습니다. 최종 사용자가 setuptools 같은 더 새로운 빌드 시스템이나 twine 같은 개선된 PyPI 업로드 유틸리티를 더 쉽게 설치하고 업그레이드할 수 있게 되면 이전 버전의 Python에서의 상황은 더욱 개선됩니다.

메타데이터 비중이 더 크고 능동성이 덜한 배포 형식과 함께 별도의 설치 프로그램을 사용하는 이 제안 모델이 대부분의 운영 체제(설치 관리자 서비스와 MSI 파일 형식이 도입된 이후의 Windows 포함)와 다른 많은 언어별 설치 프로그램에서 사용하는 모델과 일치하는 것은 우연이 아닙니다.

Python 2.6의 경우, 이 호환성 문제는 대체로 여러 엔터프라이즈 Linux 배포판(과 그 다운스트림 파생 배포판)에 국한됩니다. 이러한 배포판은 CPython보다도 업데이트 주기가 느린 경우가 많아서, 업스트림에서 “보안 수정 전용”으로 간주되는 파이썬 버전까지 완전히 지원합니다(때로는 핵심 개발 팀이 더 이상 전혀 지원하지 않는 버전까지 지원하기도 합니다. 정말 필요하다면 파이썬 2.3에 대한 상용 지원도 여전히 받을 수 있습니다!).

실제로 Linux 시스템에서는 wget과 curl 같은 도구를 쉽게 사용할 수 있고, Linux의 Python 사용자 대부분은 이미 명령줄에 익숙하며, 대부분의 Linux 배포판은 Python 스크립트를 쉽게 실행할 수 있는 기본 설정으로 제공되므로, 모든 *nix 시스템에 대한 기존 pip 부트스트래핑 안내는 이미 상당히 간단합니다. 시스템 패키지 관리자가 pip를 제공하지 않더라도, wget이나 curl로 www.pip-installer.org에서 부트스트랩 스크립트를 받아 실행하는 것은 필요할 때 쉽게 복사해 붙여 넣을 수 있는 셸 명령 몇 줄에 불과합니다.

따라서 모든 *nix 시스템의 모든 Python 버전에 대해, 이전 버전에서 pip를 부트스트랩해야 하는 필요성은 새 패키징 표준 채택의 주요 장벽으로 간주되지 않습니다. 이는 이러한 장기 안정 릴리스의 사용자가 마주치는 작은 과속 방지턱 하나에 불과하기 때문입니다. *nix 시스템의 경우, 이 PEP가 pip를 선호되는 기본 패키징 도구로 공식 지지한다는 점이 pip를 기본으로 제공하는 데 관련된 기술적 세부 사항보다 더 중요하게 여겨집니다. 이를 통해 pip 개발자와 pip 및 CPython의 다운스트림 재패키징 담당자 사이의 논의 성격이 바뀌기 때문입니다.

반면에 파이썬 2.7의 경우, 새로운 메타데이터 표준 채택에 관한 호환성 문제가 훨씬 광범위합니다. Windows와 Mac OS X용 python.org 바이너리 설치 프로그램은 물론, 비교적 빠르게 변화하는 *nix 플랫폼에도 영향을 미치기 때문입니다.

첫째, Python 2.6과 달리 Python 2.7은 여전히 업스트림에서 완전히 지원되는 버전이며, Python 2.7.9 릴리스(현재 2015년 5월 예정)까지 그 상태를 유지하고, 그 시점에 통상적인 “보안 수정 전용” 모드에 들어갈 것으로 예상됩니다. 즉, Python 2.7이 업스트림의 완전한 지원을 받는 Python 애플리케이션 배포 대상으로 남는 기간이 적어도 19개월 더 있습니다. 코어 개발 팀이 2015년에 2.7을 보안 릴리스 전용 모드로 전환한 후에도, Python 2.7은 2020년 이후까지 상업적으로 지원되는 레거시 대상으로 남을 가능성이 높습니다.

Python 2에 대한 기존 투자가 없고 특정 Python 2 전용 서드파티 모듈(이 집합은 시간이 지남에 따라 점점 작아지고 있습니다)에 대한 의존성이 없는 새로운 Python 애플리케이션과 배포에 대해서는 Python 3가 이미 Python 2보다 매력적인 대안이지만, 기존 Python 2.7 기반 인프라를 Python 3로 업데이트할 설득력 있는 비즈니스 사례를 만드는 데에는 더 오랜 시간이 걸릴 것입니다. 특히 자동화된 테스트 문화가 약하거나(또는 아예 없어서) 사용 가능한 마이그레이션 유틸리티를 효과적으로 사용하기 어려운 상황에서는 더욱 그렇습니다.

이 PEP는 Python 2.7에 대해서는 문서 변경만을 제안하지만, pip의 Windows 설치 프로그램이 마련되면 향후 CPython 2.7 유지보수 릴리스를 위해 CPython, pip, Windows용 Python 런처(Python Launcher for Windows)의 설치 프로그램을 하나의 다운로드로 결합한 통합 설치 프로그램의 제작과 배포를 제안하는 별도의 PEP를 작성하여 제출할 것입니다(개별 다운로드는 계속 제공되며, 통합 설치 프로그램은 편의를 위해, 그리고 Windows 시스템에서 Python에 권장되는 운영 환경을 분명하게 보여 주기 위해 제공될 것입니다).

왜 pip인가?

pip는 이미 널리 쓰이는 도구이면서 이전 도구인 easy_install의 여러 설계 및 사용자 경험 문제를 해결하므로 선호되는 기본 설치 프로그램으로 선택되었습니다(이러한 문제는 하위 호환성 우려 때문에 easy_install 자체에서는 쉽게 수정할 수 없습니다). 또한 pip는 단일 파이썬 런타임 설치(관련 가상 환경 포함)의 범위 안에서 동작하기에 적합하며, 이는 CPython에 번들로 포함되는 도구로서 바람직한 특성입니다.

zc.buildout과 conda 같은 다른 도구는 목표가 더 야심 차므로(그래서 외부 바이너리 의존성을 처리하는 데 pip보다 상당히 뛰어나므로), Python 생태계가 이들을 기본 크로스 플랫폼 설치 도구로 취급하기보다는 상호 운용할 플랫폼 패키지 관리자에 더 가깝게 취급하는 것이 합리적입니다. 이 관계는 pip와 apt, yum 같은 플랫폼 패키지 관리 시스템(역시 임의의 바이너리 의존성을 처리하도록 설계되었습니다) 사이의 관계와 비슷합니다.

제안 개요

이 PEP는 Installing Python Modules 안내서를 갱신하여, setup.py install 명령을 직접 호출하도록 권장하는 현재 방식 대신 Python 패키지의 기본 설치 프로그램으로 pip 사용을 공식적으로 권장할 것을 제안합니다.

다만 CPython이 제공하지 않는 도구를 권장하는 일을 피하기 위해, CPython 3.4 이상을 설치할 때와 표준 라이브러리의 venv 모듈을 pyvenv 명령줄 유틸리티로 사용하여 가상 환경을 만들 때 pip 패키지 관리자를 기본으로 사용할 수 있게 할 것도 함께 제안합니다.

그 목적을 지원하기 위해, 이 PEP는 Python 3.4에 ensurepip 부트스트래핑 모듈을 포함하고, pyvenv에서 그 모듈을 자동으로 호출하며, Windows에서 Python이 설치한 스크립트를 처리하는 방식을 변경할 것을 제안합니다. pip를 직접 제공하는 대신 부트스트랩 모듈을 사용하면 개발 책임을 명확히 구분하고, CPython을 업데이트할 때 의도치 않게 pip가 다운그레이드되는 일을 방지하는 데 도움이 됩니다.

최신 릴리스로 시작하지 않을 수도 있는 Python 신규 사용자에게 명확한 안내를 제공하기 위해, 이 PEP는 Python 2.7과 3.3의 “Python 모듈 설치하기(Installing Python Modules)” 안내서를 갱신하여 distutils를 직접 호출하는 대신 pip를 설치하여 사용하도록 권장할 것도 제안합니다. 다만 Python 3.4에 제안되는 코드 변경 사항을 백포트하는 것은 제안하지 않습니다.

마지막으로, 이 PEP는 CPython 재배포자와 다른 Python 구현이 pip를 기본으로 사용할 수 있도록 하거나, 최소한 포함되지 않았다는 사실을 명시적으로 문서화할 것을 강력히 권장합니다.

이 PEP는 pip(또는 그 의존성)를 표준 라이브러리의 일부로 직접 제공하는 것을 제안하지 않습니다. 대신 pip는 Python 사용자의 편의를 위해 CPython과 함께 제공되는 번들 애플리케이션이 되지만, 자체 개발 수명 주기를 따르며 코어 인터프리터 및 표준 라이브러리와 독립적으로 업그레이드할 수 있습니다.

명시적 부트스트래핑 메커니즘

ensurepip라는 모듈이 표준 라이브러리에 추가로 포함되며, 이 모듈의 목적은 pip와 그 의존성 패키지를 적절한 위치(가장 일반적으로는 site-packages)에 설치하는 것입니다. 이 모듈은 bootstrap()이라는 호출 가능 객체를 노출하고, python -m ensurepip을 통한 직접 실행도 제공합니다.

부트스트랩은 PyPI에 접속하지 않으며, 대신 표준 라이브러리 내부에 저장된 pip의 비공개 사본에 의존합니다. 따라서 설치 위치와 관련된 옵션(--user, --root 등)만 지원됩니다.

PyPI 기반 생태계의 보안을 개선하려는 지속적인 노력의 혜택을 누리고, 그 생태계의 속도, 신뢰성, 유연성을 개선하려는 노력의 혜택도 받을 수 있도록, 사용자에게 사용 가능한 최신 버전의 pip를 사용하도록 강력히 권장하는 것이 바람직하다고 봅니다.

기본으로 최신 버전의 pip를 제공한다는 이 목표를 충족하기 위해, pip의 비공개 사본은 CPython 유지보수 릴리스에서 갱신되며, 이는 새 pip 릴리스에 사용되는 6개월 주기와 잘 맞을 것입니다.

보안 고려 사항

이 PEP의 설계는 이후에 pip install --upgrade pip 명령을 실행하지 않는 최종 사용자에 대해서는 CPython의 신뢰 모델에 어떠한 중대한 변경도 가하지 않도록 의도적으로 선택되었습니다.

설치 프로그램에는 pip 설치 프로그램을 포함하여, 완전히 동작하는 Python 버전의 모든 구성 요소가 담깁니다. 설치 과정은 네트워크 접근을 필요로 하지 않으며, pip와 Python 패키지 색인 사이에 수립된 네트워크 연결의 보안을 신뢰하는 데 의존하지도 않습니다.

pip를 사용해 PyPI와 통신하기로 선택한 사용자만 그에 따르는 추가적인 보안 고려 사항에 주의를 기울이면 됩니다.

그렇지만 CPython 코어 팀은 현재 requests 프로젝트(따라서 pip도)에 영향을 주고 있는 인증서 갱신 관리 문제를 최소한 검토하고 해결하는 일은 계속 지원할 것이며, 확인된 다른 보안 우려 사항을 해결하는 데에도 도움을 줄 수 있을 것입니다 [1].

신뢰성 고려 사항

부트스트랩을 (바이너리 설치 프로그램의 기능으로만 두는 대신) 표준 라이브러리의 일부로 포함함으로써, 설치 프로그램 자체의 테스트 부담을 크게 늘리지 않고도 기존 CPython buildbot 인프라를 사용하여 부트스트랩 명령이 올바르게 동작하는지 쉽게 테스트할 수 있습니다.

구현 전략

Python을 설치하거나 가상 환경을 만들 때 네트워크 접근이 필요하지 않도록, ensurepip 모듈은 구현 세부 사항으로서 pip와 그 의존성의 완전한 비공개 사본을 포함하며, 이 사본은 pip를 추출하여 대상 환경에 설치하는 데 사용됩니다. 이 pip 비공개 사본은 단지 구현 세부 사항일 뿐이며, ensurepip 모듈을 통해(그리고 간접적으로는 venv를 통해) 노출되는 공개 기능 이상으로 이에 의존하거나 그 존재를 가정해서는 안 된다는 점을 강조하는 것이 중요합니다.

아직 ensurepip의 참조 구현은 없습니다. 기존 get-pip.py 부트스트랩 스크립트는 일반적인 개념의 초기 변형을 보여 주지만, 표준 라이브러리 버전은 CPython 설치 프로그램이 제공하는 개선된 배포 기능을 활용하여 pip와 setuptools의 비공개 사본을 (base64로 인코딩되어 내장된 데이터가 아니라) wheel 파일로 포함할 것이며, PyPI에 접속하려 하지 않을 것입니다(대신 비공개 wheel 파일에서 직접 설치합니다).

부트스트래핑을 처리하는 별도의 코드를 포함하는 대신, ensurepip 모듈은 sys.path를 적절히 조작하여 wheel 파일이 스스로를 현재 Python 설치 또는 가상 환경(부트스트랩 명령에 전달된 옵션에 따라 결정됨)에 설치할 수 있게 합니다.

구현은 다섯 개의 개별 단계로 수행할 것을 제안합니다(처음 두 단계 이후의 모든 단계는 서로 독립적이며 어떤 순서로든 수행할 수 있습니다):

  • 첫 번째 단계에서는 “Python 모듈 설치하기(Installing Python Modules)” 문서를 갱신하여 pip의 사용을 권장하고, pip 팀이 제공하는 다운로드 및 설치 안내를 참조하도록 합니다. 이 변경은 Python 2.7, 3.3, 3.4에 적용됩니다.
  • ensurepip 모듈과 가장 최근에 릴리스된 pip 및 setuptools 버전의 비공개 사본을 Python 3.4에 추가하고, 이에 맞춰 3.4의 “Installing Python Modules” 문서를 갱신합니다.
  • CPython Windows 설치 프로그램을 갱신하여 Python 3.4용 새 pip 설치 옵션을 제공합니다.
  • CPython Mac OS X 설치 프로그램을 갱신하여 Python 3.4용 새 pip 설치 옵션을 제공합니다.
  • Python 3.4에서는 venv 모듈과 pyvenv 명령이 ensurepip을 사용하도록 갱신됩니다.
  • Python 3.4 이상에서는 Windows의 PATH 처리가 갱신됩니다.

통합 일정

이 PEP가 수락되면, pip을 CPython 릴리스에 통합하기 위해 제안하는 일정은 다음과 같습니다:

  • 3.4.0 알파 4 릴리스 이후 가능한 한 빨리
    • 문서를 갱신하고, pip 1.5의 사전 릴리스 버전을 기반으로 ensurepip을 구현합니다.
    • 설치 프로그램이 ensurepip을 호출하도록 하는 갱신을 포함하여, Python 3.4에 대해 제안된 나머지 모든 기능 변경을 구현합니다.
  • 11월 20일까지(3.4.0 베타 1 예정일 3일 전)
    • pip 1.5 릴리스 후보를 사용하도록 ensurepip을 갱신합니다.
    • 번들된 pip 버전이 최신 상태인지 확인하는 절차를 다루도록 PEP 101을 갱신합니다.
  • 11월 24일까지(3.4.0 베타 1 예정일)
    • 다른 모든 새 기능과 마찬가지로, Python 3.4에 대해 제안된 모든 기능 변경은 베타 기능 동결 전에 구현되어야 합니다.
  • 12월 29일까지(3.4.0 베타 2 예정일 1주 전)
    • requests 인증서 관리 문제를 해결합니다.
    • ensurepip을 pip 1.5의 최종 릴리스 또는 그 이후의 유지보수 릴리스(적절히 갱신된 requests 벤더링 사본 포함)로 갱신합니다.

(각 릴리스의 현재 공식 예정일은 PEP 429를 참조하십시오. 위에 나열된 날짜는 2013년 10월 20일 기준으로 정확합니다.)

예정된 Python 3.4 베타 2 릴리스 1주 전까지 적절히 갱신된 requests 버전을 포함한 pip 1.5의 최종 릴리스나 유지보수 릴리스가 나오지 않으면, 이 PEP의 구현은 Python 3.5로 연기됩니다. 다만 이런 상황은 일어날 가능성이 낮다고 봅니다. 현재 pip 1.5 릴리스의 잠정 일자는 12월 1일입니다.

향후 CPython 릴리스에서는 이런 식의 일정 조율이 필요하지 않을 것입니다. CPython 릴리스 관리자가 pip의 최신 릴리스 버전으로 갱신하기만 하면 됩니다. 하지만 이번에는 번들링이 올바르게 동작하도록 pip에 몇 가지 수정이 필요하고, requests의 인증서 갱신 메커니즘도 개선되어야 하므로, pip 1.5 릴리스 주기를 CPython 3.4 베타 릴리스와 적절히 맞춰야 합니다.

제안하는 CLI

제안하는 CLI는 기존 pip install 옵션의 일부를 기반으로 합니다.:

Usage:
  python -m ensurepip [options]

General Options:
  -h, --help          Show help.
  -v, --verbose       Give more output. Option is additive, and can be used up to 3 times.
  -V, --version       Show the pip version that would be extracted and exit.
  -q, --quiet         Give less output.

Installation Options:
  -U, --upgrade       Upgrade pip and dependencies, even if already installed
  --user              Install using the user scheme.
  --root <dir>        Install everything relative to this alternate root directory.

대부분의 경우 pip은 Python을 설치하거나 가상 환경을 만들 때 자동으로 설치되어 있을 것이므로, 최종 사용자가 이 CLI를 직접 사용할 필요는 없습니다. 그러나 적어도 다음과 같은 알려진 사용 사례를 지원하기 위해 공개 인터페이스로서 공식적으로 문서화됩니다:

  • 설치 중에 “Install pip” 옵션을 선택하지 않은 Windows 및 Mac OS X 설치
  • 사용자가 이전에 “pip uninstall pip”를 실행한 모든 설치

PyPI에서 최신 버전을 받으려 하거나 그 밖에 더 많은 유연성이 필요한 사용자는, 이후 추출된 pip을 적절히 호출하면 됩니다.

제안하는 모듈 API

제안하는 ensurepip 모듈 API는 다음 두 함수로 구성됩니다.:

def version():
    """
    Returns a string specifying the bundled version of pip.
    """

def bootstrap(root=None, upgrade=False, user=False, verbosity=0):
    """
    Bootstrap pip into the current Python installation (or the given root
    directory).
    """

CPython 설치 프로그램에서의 호출

CPython Windows 및 Mac OS X 설치 프로그램에는 각각 새로운 옵션이 추가됩니다:

  • pip(기본 Python 패키지 관리 유틸리티)를 설치하시겠습니까?

이 옵션은 기본적으로 선택되어 있습니다.

이 옵션이 선택되어 있으면 설치 프로그램은 방금 설치된 Python으로 다음 명령을 호출합니다:

python -m ensurepip --upgrade

이렇게 하면 기본적으로 CPython을 설치하거나 업데이트할 때, 설치된 pip 버전이 적어도 해당 CPython 버전에 포함된 pip만큼 최신임이 보장됩니다. 더 새로운 버전의 pip가 이미 설치되어 있다면 python -m ensurepip --upgrade는 아무 작업도 하지 않고 그냥 반환합니다.

소스에서 설치하기

미리 빌드된 바이너리 설치 프로그램이 기본적으로 python -m ensurepip을 실행하도록 업데이트되는 것과 마찬가지로, 소스 배포판의 make install 및 make altinstall 명령에도 비슷한 변경이 적용됩니다. sysconfig 모듈의 디렉터리 설정을 통해 pip 구성 요소가 예상된 위치에 자동으로 설치될 것입니다.

ensurepip 자체(pip의 비공개 사본과 그 의존성 포함)는 표준 라이브러리의 일반적인 일부이므로 항상 정상적으로 설치되지만, ensurepip 호출을 건너뛰는 옵션이 제공됩니다.

즉, 소스에서 설치하더라도 기본적으로 pip가 제공되지만, 다른 방법으로 pip를 제공하는(또는 전혀 제공하지 않는) 재배포자는 여전히 ensurepip을 사용한 설치를 선택적으로 제외할 수 있습니다.

가상 환경의 변경 사항

Python 3.3에는 venv 모듈을 통해 가상 Python 환경을 다루는 표준 라이브러리 방식이 포함되었습니다. 출시 이후, 이 기능을 직접 사용하려는 사용자가 매우 적다는 것이 분명해졌는데, 그 이유 중 하나는 가상 환경 안에 기본적으로 설치 프로그램이 없기 때문입니다. 대신 사용자들은 기본적으로 pip가 설치되어 있는 virtualenv 패키지를 계속 사용하는 쪽을 선택했습니다.

venv를 사용자에게 더 유용하게 만들기 위해, 새 환경을 생성할 때 기본적으로 그 환경 안에서 pip 부트스트랩을 수행하도록 수정합니다. 이를 통해 사람들은 이 PEP가 가상 환경 밖에서 제공하는 것과 같은 편의를 가상 환경 안에서도 누릴 수 있으며, 동시에 venv 모듈이 외부 virtualenv 패키지와 기능적으로 더 대등해져 더 적합한 대체재가 됩니다.

사용자가 자신의 가상 환경에 pip가 부트스트랩되기를 원하지 않는 경우를 처리하기 위해 --without-pip 옵션이 추가됩니다.

venv.EnvBuilder 및 venv.create API는 새 매개변수 하나, with_pip(기본값은 False)를 받도록 업데이트됩니다.

모듈 API의 새 기본값은 현재 동작과의 하위 호환성을 위해 선택되었으며(venv 모듈 호출 대부분은 명시적으로 요청하지 않는 한 pip가 설치되기를 원하지 않을 가능성이 높은 서드파티 도구를 통해 이루어진다고 가정하기 때문입니다), 명령줄 인터페이스의 기본값은 최종 사용자가 별도의 조치를 취하지 않아도 대부분의 가상 환경에서 pip를 사용할 수 있도록 하기 위해 선택되었습니다.

이 변경은 Python 3.4 이상 버전에만 이점이 있으므로, Python 3.3과 2.7에서 버전 간에 일관된 경험을 얻으려면 여전히 서드파티 virtualenv 프로젝트가 필요합니다.

문서

Python 2.7, 3.3, 3.4의 표준 라이브러리 문서 중 “Python 모듈 설치하기” 절은 Python 3.4에서는 기본으로 제공되고 Python 2.7이나 3.3에서는 사용자가 직접 받아 설치하는 pip 설치 프로그램의 사용을 권장하도록 업데이트됩니다. 이 절에서는 가장 일반적인 명령과 옵션을 간략히 설명하지만, 자세한 내용은 외부에서 유지 관리되는 pip 문서에 맡깁니다.

Python 3.4에서는 pyvenv 및 venv 문서도 개정된 모듈 설치 안내서를 참조하도록 업데이트됩니다.

모듈 설치 안내서의 기존 내용은 모든 버전에서 유지되지만, 새로운 “distutils 직접 호출하기” 하위 절 아래로 옮겨집니다.

CPython에 CA 인증서 번들 포함하기

ensurepip 구현에는 pip의 나머지 부분과 함께 pip CA 번들이 포함됩니다. 즉, CPython은 사실상 CA 번들을 포함하게 되며, 이 번들은 추출된 후 오직 pip만 사용합니다.

이는 시스템 인증서 저장소에만 의존하는 것보다 바람직하다고 여겨지는데, Windows에서 시스템 인증서 저장소에 접근할 수 없는 Python 3.4 이전 버전까지 포함하여 지원되는 모든 Python 버전에서 pip가 동일하게 동작하도록 보장하기 때문입니다.

setuptools 자동 설치

pip는 현재 빌드 과정에서의 메타데이터 생성 및 기타 몇몇 기능을 처리하기 위해 setuptools에 의존합니다. 이 의존성을 줄이거나 없애기 위한 작업이 진행 중이지만, 그 작업이 pip 1.5(Python 3.4.0이 출시될 때 최신 버전일 가능성이 높은 버전)에 맞춰 완료될지는 확실하지 않습니다.

이 PEP는 pip가 여전히 의존성으로 요구하는 경우 ensurepip가 (ensurepip의 비공개 사본에 더해) setuptools의 비공개 사본을 포함할 것을 제안합니다. 그러면 python -m ensurepip은 pip 자체를 설치하는 것에 더해 이 비공개 사본도 설치합니다.

그러나 이 동작은 공식적으로 구현 세부 사항으로 간주됩니다. setuptools를 명시적으로 요구하는 다른 프로젝트는 setuptools가 항상 pip와 함께 설치된다고 가정하지 말고, 여전히 적절한 의존성 선언을 제공해야 합니다.

setuptools의 비공개 사본은 더 이상 필요하지 않게 되면 ensurepip에서 제거됩니다. 그 시점은 get-pip.py가 기본적으로 setuptools를 설치하지 않게 될 때일 가능성이 높습니다. setuptools가 필요한 동안에는 최신 업스트림 setuptools 릴리스를 전혀 수정하지 않은 사본을 사용하며, 업스트림 setuptools가 계속 easy_install 스크립트를 포함한다면 그 스크립트도 포함됩니다. pip와 함께 easy_install이 설치되는 것은 바람직하지 않다고 여겨지지만, 망가진 setuptools를 설치하는 것은 더 나쁩니다. 이 문제는 pip 개발자들이 setuptools에 대한 의존성을 없애는 데 성공하여 setuptools의 비공개 사본을 CPython에서 완전히 제거할 수 있게 되면 자연스럽게 해결될 것입니다.

pip 비공개 사본 갱신

패키징의 발전을 따라가는 동시에 사용자에게 가능한 한 최신 버전을 제공하기 위해, ensurepip 모듈은 부트스트랩하는 모든 구성 요소의 최신 버전으로 정기적으로 갱신됩니다.

새로운 pip 릴리스가 나올 때마다, 그리고 (기능 릴리스를 포함한) 모든 Python 릴리스를 준비하는 동안 다시 한 번, 이 PEP 구현의 일부로 제공되는 스크립트를 실행하여 CPython 소스 저장소에 저장된 비공개 사본들이 최신 버전으로 갱신되었는지 확인합니다.

ensurepip 모듈 API 및 CLI 갱신

venv 및 pyvenv와 마찬가지로, ensurepip 모듈 API와 CLI에는 표준 라이브러리의 일반 규칙이 적용됩니다. 즉, 유지보수 릴리스에서는 새로운 기능이 허용되지 않습니다.

그러나 내장된 구성 요소는 위에서 설명한 대로 갱신될 수 있으므로, 추출된 pip는 유지보수 릴리스에서 추가 기능을 제공할 수 있습니다.

제거

이 PEP는 CPython 제거 과정에 대한 변경을 제안하지 않습니다. 부트스트랩된 pip는 pip로 설치된 다른 패키지와 같은 방식으로 설치되며, Python 환경에 설치 후 추가된 다른 모든 항목과 같은 방식으로 처리됩니다.

이는 적어도 Windows에서는 부트스트랩된 파일이 Python MSI 설치 프로그램과 연결되지 않으므로 제거 후에도 남게 된다는 뜻입니다.

CPython 설치 프로그램이 이러한 디렉터리를 자동으로 정리해야 한다는 주장도 가능하지만, 그 동작을 변경하는 것은 이 PEP의 범위를 벗어나는 것으로 간주됩니다.

Windows에서의 스크립트 실행

Windows 설치 프로그램은 Python 3.3에서 선택적으로 python을 PATH에서 사용할 수 있도록 갱신되었지만, sysconfig.get_path("scripts")가 반환하는 스크립트 설치 디렉터리를 포함하도록 하는 변경은 이루어지지 않았습니다.

따라서 이 PEP는 설치 중에 pip를 추출하고 설치하는 옵션을 추가하는 것에 더해, 설치 중에 PATH 수정 옵션이 활성화된 경우 sysconfig.get_path("scripts")가 반환하는 경로도 Windows PATH에 추가하도록 Python 3.4 이상의 Windows 설치 프로그램을 갱신할 것을 제안합니다

이 변경은 Python 3.4 이상에서만 사용할 수 있다는 점에 유의하십시오.

이는 Python 3.3의 경우, Windows에서 (PATH를 수동으로 건드리지 않고) pip를 전역적으로 호출하는 가장 확실한 방법이 여전히 단순히 pip를 호출하는 것이 아니라 py -m pip(또는 Python 2와 3이 모두 설치된 경우 Python 3 버전을 선택하기 위한 py -3 -m pip)라는 뜻입니다. 이 방법이 동작하는 이유는 Python 3.3이 기본적으로 Windows용 Python 런처(및 관련 py 명령)를 제공하기 때문입니다.

Python 2.7과 3.2의 경우, 가장 확실한 방법은 독립 실행형 설치 프로그램으로 Windows용 Python 런처를 설치한 다음 위에서 설명한 대로 py -m pip를 사용하는 것입니다.

스크립트 디렉터리를 시스템 PATH에 추가하면 “시스템 PATH에 Python 설치가 하나만 있는” 경우 pip가 안정적으로 동작하게 되며, py -m pip, pipX 또는 pipX.Y는 병렬 설치된 경우(그리고 가상 환경 밖에서) 기본값이 아닌 버전을 선택할 때만 필요하게 됩니다. 또한 이 변경으로 Windows에서 pip, easy_install 및 유사한 도구가 설치하는 모든 스크립트와 함께 pyvenv 명령도 훨씬 쉽게 호출할 수 있게 될 것입니다.

최근 버전의 Python에서는 스크립트 호출이 Windows용 Python 런처를 거쳐 실행되지만, Scripts 디렉터리에 있는 Python 파일이 셔뱅 줄에 Python 버전을 올바르게 지정하거나 (easy_install과 pip처럼) 인접한 Windows 실행 파일을 가지고 있는 한 아무런 문제도 일으키지 않을 것입니다.

다운스트림 배포자를 위한 권장 사항

Python 설치의 일반적인 출처로는 다양한 Linux 배포판 [3] [4] [5], OSX 패키지 관리자 [6] [7] [8], 상용 Python 재배포자 [9] [10] [11]와 같은 다운스트림 배포자가 있습니다. Python을 어떻게 얻었는지와 관계없이 모든 Python 사용자에게 일관되고 사용자 친화적인 경험을 제공하기 위해, 이 PEP는 다운스트림 배포자에게 다음을 권장하고 요청합니다:

  • Python이 설치될 때마다 pip도 함께 설치되거나, 그렇지 않더라도 최종 사용자가 쉽게 사용할 수 있도록 하십시오.
    • 바이너리 설치 프로그램을 사용하는 재배포자라면 CPython 설치 프로그램처럼 설치 중에 ensurepip 부트스트랩을 선택적으로 실행하는 방식을 택할 수 있습니다.
    • 패키지 관리 시스템을 사용하는 재배포자의 경우, 이는 서로 의존성을 갖는 별도의 패키지 형태를 띨 수 있으며, 이를 통해 Python 패키지를 설치하면 pip 패키지가 설치되고 pip 패키지를 설치하면 Python 패키지가 설치되도록 할 수 있습니다.
    • 이를 구현하는 또 다른 합리적인 방법은 pip을 별도로 패키징하되, pip이 설치되지 않은 상태에서 사용자가 pip을 실행하면 별도의 pip 패키지를 설치하도록 권하는 일종의 전역 훅을 마련하는 것입니다. 이 방식을 선택하는 시스템은 ensurepip 모듈이 가상 환경 안에서 호출될 때는 여전히 pip을 직접 설치하도록 보장해야 합니다. 다만 pip을 전역으로 설치할 때는 플랫폼이 제공하는 메커니즘으로 리디렉션하도록 시스템 Python 설치본의 모듈을 수정할 수 있습니다.
  • 다른 수단으로 pip을 전역에서 사용할 수 있게 하더라도 Python 3.4 이상에서는 ensurepip 모듈을 제거하지 마십시오.
    • venv 모듈이 가상 환경에 pip을 자동으로 설치하려면 ensurepip이 필요합니다.
    • 이는 기존 virtualenv 패키지와 비슷합니다. 많은 다운스트림 배포자가 이미 이 패키지를 일반적인 “번들 해제(debundling)” 정책의 예외로 두고 있습니다.
    • 이는 보안 문제로 pip을 업데이트해야 한다면 ensurepip 부트스트랩 모듈 안의 비공개 사본도 업데이트해야 한다는 뜻입니다
    • 그러나 pip의 비공개 사본을 수정하여 내장된 CA 인증서 번들을 제거하고 대신 시스템 CA 번들을 사용하도록 하는 것은 합리적인 변경입니다.
  • 재배포하는 Python 버전에 어떤 수정을 가하더라도 이 PEP의 모든 기능이 계속 동작하도록 하십시오.
    • python -m ensurepip --version 또는 ensurepip.version()을 사용하여 부트스트랩될 pip의 버전을 확인하는 것.
    • python -m ensurepip 또는 ensurepip.bootstrap()을 사용하여 전역 또는 가상 Python 환경에 pip을 설치하는 것.
    • 전역 설치본에서 실행한 pip install --upgrade pip은 이미 생성된 가상 환경에 영향을 주어서는 안 됩니다(앞으로 생성될 가상 환경에는 영향을 주어도 되지만, ensurepip의 표준 구현을 사용할 때는 그렇게 되지 않습니다).
    • 가상 환경에서 실행한 pip install --upgrade pip은 전역 설치본에 영향을 주어서는 안 됩니다.
  • 가능한 모든 곳에서 빌드 시스템이 pip과 Wheel을 사용하도록 이전하고, setup.py를 직접 호출하지 마십시오.
    • 이렇게 하면 Python 패키징 생태계가 계속 발전함에 따라 개선된 메타데이터 형식으로 더 원활하고 시기적절하게 이전하는 데 도움이 됩니다.

Python 재배포자가 이 권고를 따르지 않기로 선택한 경우, 그 사실을 명시적으로 문서화하고, 업스트림의 pip 기반 설치 안내를 해당 플랫폼에 맞는 방식으로 바꾸는 방법을 사용자에게 적절히 안내해 주시기 바랍니다.

다른 Python 구현도 해당하는 경우에는 이 지침을 따르기를 권장합니다.

정책 및 거버넌스

부트스트랩되는 소프트웨어의 유지 관리자와 CPython 코어 팀은 양측의 요구를 해결하기 위해 함께 협력할 것입니다. 부트스트랩되는 소프트웨어는 계속 CPython 외부에 남으며, 이 PEP는 CPython이 부트스트랩되는 소프트웨어의 개발 책임이나 설계 결정을 넘겨받는 것을 포함하지 않습니다. 이 PEP는 서드파티 패키지를 사용하려는 최종 사용자의 부담을 줄이는 것을 목표로 하며, 이 PEP 안의 결정들은 Python 커뮤니티가 pip, setuptools, PyPI, virtualenv 및 기타 관련 프로젝트의 작성자이자 유지 관리자인 Python 패키징 기관(Python Packaging Authority)에 이미 보내고 있는 신뢰를 반영한 실용적인 결정입니다.

하위 호환성

ensurepip 모듈 자체의 공개 API와 CLI에는 Python 표준 라이브러리에 적용되는 일반적인 하위 호환성 정책이 적용됩니다. 이 PEP가 번들로 포함하는 외부 개발 소프트웨어에는 이 정책이 적용되지 않습니다.

가장 중요한 점은, 이것이 부트스트랩되는 pip 버전이 CPython 유지보수 릴리스에서 새 기능을 얻을 수 있으며, pip가 CPython의 18~24개월 주기가 아닌 자체 6개월 릴리스 주기로 계속 운영된다는 것을 의미한다는 점입니다.

보안 릴리스

ensurepip 모듈에 영향을 주는 모든 보안 업데이트는 릴리스 전에 Python 보안 대응 팀(security@python.org)과 공유됩니다. 그러면 PSRT는 보고된 문제가 pip의 비공개 사본을 업데이트한 CPython 보안 릴리스를 낼 만한 사안인지 결정합니다.

라이선스

pip는 현재 1절(1 Clause) BSD 라이선스를 따르며, 다른 프로젝트에서 가져온 코드를 포함하고 있습니다. 또한 이 PEP는 pip이 더 이상 setuptools를 필요로 하지 않게 될 때까지 setuptools를 포함합니다. 이들의 라이선스는 아래 표에 나와 있습니다.

프로젝트 라이선스
requests Apache 2.0
six 1절(1 Clause) BSD
html5lib 1절(1 Clause) BSD
distlib PSF
colorama 3절(3 Clause) BSD
Mozilla CA Bundle LGPL
setuptools PSF

이 라이선스들은 모두 PSF 라이선스와 호환될 것입니다. 또한 CA Bundle이 저작권 보호 대상인지, 따라서 애초에 라이선스가 필요한지 또는 라이선스를 부여할 수 있는지조차 불분명합니다.

부록: 거부된 제안

Windows에서 스크립트 디렉터리 이름 변경

이 PEP의 이전 버전에서는 pyvenv가 생성하는 가상 환경의 크로스 플랫폼 일관성을 높이기 위해 Windows의 스크립트 설치 디렉터리 이름을 “Scripts”에서 “bin”으로 변경할 것을 제안했습니다.

그러나 Paul Moore는 이 변경이 이전 버전의 Python으로 만든 교차 버전 Windows 설치 프로그램과 하위 호환되지 않을 가능성이 높다고 판단했으며, 이에 따라 이 변경은 이 PEP에서 제거되었습니다 [2].

Python 2.7 및 3.3에 ensurepip 포함

이 PEP의 이전 버전에서는 새 사용자를 위해 pip을 부트스트랩하는 데 따르는 어려움이 Python의 향후 성장에 상당한 장벽이 되므로, 곧 나올 Python 2.7 및 3.3 유지보수 릴리스에 ensurepip을 새 기능으로 추가하는 것이 정당하다고 주장했습니다.

Python 3.4와 함께 pip을 제공하자는 제안은 모두의 호응을 얻었지만, 제안의 이 부분은 큰 논란을 불러일으켰고 결국 BDFL-Delegate인 MvL이 거부했습니다.

이에 따라, ensurepip을 Python 2.7과 3.3에 백포트하자는 제안은 이 PEP에서 제거되었으며, 그 대신 pip용 Windows 설치 프로그램을 만들고, 향후 CPython 2.7, pip, Windows용 Python 런처를 결합한 Python 2.7용 통합 설치 프로그램을 만들자고 제안하는 PEP가 나올 수도 있습니다.

pip 부트스트랩 시 PyPI에 자동으로 접속

이 PEP의 이전 버전에서는 부트스트랩 모듈을 getpip이라고 불렀으며, 기본적으로 PyPI에서 pip을 내려받아 설치하고, 비공개 사본은 대체 수단으로만 또는 명시적으로 요청한 경우에만 사용했습니다.

이로 인해 여러 복잡한 예외 상황(edge case)이 생겼고, 부트스트랩 모듈을 위한 깔끔한 API와 CLI를 정의하기도 어려웠습니다. 또한 python.org에 게시되는 바이너리 설치 프로그램의 기본 신뢰 모델도 크게 바뀌었습니다. 최종 사용자가 PyPI 생태계의 보안을 신뢰하지 않으려면 명시적으로 옵트아웃해야 했기 때문입니다(설치 후 pip를 명시적으로 호출하여 옵트인하는 방식이 아니었습니다).

그 결과 PEP는 부트스트래핑이 항상 pip의 비공개 사본을 사용하는 현재 설계로 단순화되었습니다. 이제 PyPI에 접속하는 것은 항상 명시적인 별도 단계이며, 이 단계에서는 pip 인터페이스 전체를 직접 사용할 수 있습니다.

PyPI에 암묵적으로 접근하려는 시도를 없앤 덕분에, 사용자 정의 소스 빌드로 설치할 때 기본적으로 ensurepip를 호출하는 것도 가능해졌습니다.

암묵적 부트스트랩

이 PEP의 전신인 PEP 439는 자체적인 해결책을 제안합니다. 그 해결책은 가짜 pip 명령을 함께 배포하는 것으로, 이 명령을 실행하면 pip가 아직 없는 경우 암묵적으로 pip를 부트스트랩하여 설치합니다. 이 방식은 너무 “마법 같다”는 이유로 거부되었습니다. 이 방식은 pip 명령이 정확히 언제 설치되는지, 심지어 설치되고 있다는 사실 자체도 최종 사용자에게 숨깁니다. 또한 전역으로 설치된 pip를 자신의 시스템에서 일반적으로 쓰는 메커니즘으로 관리하려는 다운스트림 패키저를 위한 권장 사항이나 고려 사항도 전혀 제공하지 않습니다.

암묵적 부트스트랩 메커니즘은 사용자가 적절한 설치 디렉터리에 대한 쓰기 권한 없이 실수로 pip를 부트스트랩하려고 할 경우 권한 문제에 부딪힐 가능성도 있었습니다.

표준 라이브러리에 pip를 직접 포함하기

이 PEP와 유사한 것으로, 단순히 pip를 표준 라이브러리에 포함하자는 제안이 있습니다. 이렇게 하면 Python에 항상 pip가 포함되므로, pip가 기본으로 제공되지 않아 최종 사용자가 겪는 모든 문제가 해결됩니다. 이 방안은 거부되었는데, 표준 라이브러리에 distutils가 포함되어 온 과정과 그 역사를 통해, 패키징 도구를 독립적으로 갱신할 수 있는 능력을 잃으면 도구가 변하지 않는 상수처럼 끝없이 정체된 상태에 머물 수 있다는 것을 배웠기 때문입니다. 그렇게 되면 새로운 기능이 수년 동안 일반 사용자에게 제공되지 않으므로, 실제로 사용자에게 영향을 미칠 수 있는 기간 안에 도구가 합리적으로 발전하는 것이 불가능해집니다.

패키징 도구가 Python의 릴리스 및 도입 일정과 별개로 발전할 수 있게 하면, 최신 Python 릴리스를 곧바로 따라갈 수 있는 사람들뿐만 아니라 Python 커뮤니티의 모든 구성원이 개선 사항을 활용할 수 있습니다.

과거에는 프로젝트가 외부에서 계속 유지보수되면서 동시에 표준 라이브러리에서도 포크가 유지보수되는 경우 “이중 유지보수” 문제도 있었습니다. 이전 Python 버전을 지원하기 위해 pip의 외부 유지보수는 항상 필요하므로, 제안된 부트스트래핑 메커니즘은 (pip 개발자의 도움을 받아) CPython 코어 개발자의 명시적인 책임이 되며, CPython 트래커에 보고된 pip 이슈는 pip 이슈 트래커로 이전됩니다. 어떤 트래커를 사용해야 하는지를 두고 사용자가 여전히 다소 혼란을 겪겠지만, 과거에 서드파티 프로젝트의 완전한 공개 사본을 표준 라이브러리에 포함했을 때보다는 덜하기를 기대합니다.

이 PEP에서 설명하는 접근 방식은 pip가 독립적으로 더 최신 버전으로 업데이트된 상태에서 CPython 유지보수 업데이트를 처리하는 것과 관련된 몇 가지 기술적 문제도 피할 수 있습니다. 제안된 pip 기반 부트스트래핑 메커니즘은 이를 자동으로 처리합니다. pip와 시스템 설치 프로그램이 pip 설치를 누가 소유하는지를 두고 다투는 일이 결코 없기 때문입니다(pip 설치는 항상 pip를 통해 직접 관리되거나, ensurepip 부트스트랩 모듈을 통해 간접적으로 관리됩니다).

마지막으로, 부트스트래핑 단계가 분리되어 있으므로 최종 사용자가 원한다면 pip를 아예 설치하지 않는 것도 쉽습니다. 통합 작업자가 공통 도구 집합으로 여러 언어로 작성된 구성 요소의 설치를 처리하기 위해 시스템 패키지를 사용하는 경우가 흔히 이에 해당합니다.

–user 설치를 기본값으로 하기

기본적으로 pip를 사용자별 site-packages 패키지 디렉터리에 부트스트랩하는 방안도 어느 정도 검토되었습니다. 그러나 이 동작은 (pip 자체의 기본 동작과 다르기 때문에) 사용자를 놀라게 할 수 있으며, 현재로서는 신뢰할 수 있다고 여겨지지도 않습니다(pip가 시스템 site-packages가 아니라 사용자 site-packages 패키지 디렉터리에 설치될 때 올바르게 처리되지 않는 몇몇 예외적인 경우가 있습니다).

참고 문헌