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의 Python 모듈 설치 안내서를 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 패키지 색인 생태계를 효과적으로 사용하려면 사용자가 어떤 패키지 관리자를 설치해야 하는지, 어디서 구해야 하는지, 어떻게 설치해야 하는지를 알아야 한다는 의미입니다. 그 결과 현재 서드파티 Python 프로젝트는 바람직하지 않은 여러 대안 중에서 선택해야 합니다.

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

이러한 이용 가능한 모든 선택지에는 상당한 단점이 있습니다.

프로젝트가 사용자가 이미 도구를 갖추고 있다고 단순히 가정하면, 설치 명령이 작동하지 않을 때 초보 사용자는 혼란스러운 오류 메시지를 받을 수 있습니다. 일부 운영 체제는 존재하지 않는 명령을 찾고 해당 명령이 작동하도록 설치할 수 있는 운영 체제 패키지를 제안하는 전역 훅을 제공하여 이러한 문제를 완화할 수 있지만, 이는 관련 크로스 플랫폼 설치 명령을 제공하는 패키지를 포함한 플랫폼 패키지 관리자가 있는 시스템에서만 작동합니다(많은 주요 Linux 배포판이 이에 해당합니다). Windows 및 Mac OS X 사용자나 더 보수적인 Linux 배포판에서는 이러한 지원을 이용할 수 없습니다. 이 문제를 다루는 과정에서 발생하는 어려움은 (프로그래밍, 명령줄 도구 사용 및 시스템 환경 변수 편집을 완전히 처음 접하는 경우가 많은) 초보자에게 특히 크며, 전문 교육자와 신규 사용자에게 Python을 소개하는 사람들이 Python 핵심 개발자에게 보내는 피드백에서 이러한 어려움은 정기적으로 나타납니다.

프로젝트가 설치 지침을 복제하고 자체 프로젝트 설치 방법을 알려 주기 전에 패키지 관리자를 설치하는 방법을 사용자에게 알려 주기로 선택하면, 이 지침을 업데이트해야 할 때마다 이를 복제한 모든 프로젝트가 업데이트해야 합니다. 여러 경쟁 설치 도구를 이용할 수 있고 프로젝트마다 서로 다른 도구를 권장하는 경우에는 특히 문제가 됩니다.

pip 를 기본 설치 도구로 적극 홍보하고 다른 프로젝트가 지침을 복제하는 대신 pip 자체의 부트스트래핑 지침을 참조하도록 권장하면 이 특정 문제를 부분적으로 완화할 수 있습니다. 그러나 이 접근 방식으로 만들어지는 사용자 경험은 여전히 그다지 좋지 않습니다(해당 플랫폼에서 상황을 개선할 수 있도록 pip 와 그 의존성을 결합한 Windows 설치 프로그램을 만들려는 노력이 진행 중이며, Mac OS X 및 *nix 플랫폼에는 일반적으로 wget 이 있으므로 명령줄에서 부트스트랩 스크립트를 쉽게 다운로드하고 실행할 수 있습니다).

의존성을 완전히 포기하기로 결정한 프로젝트는 문제에 대한 자체 해결책을 고안하여 다른 프로젝트의 노력을 복제하거나, 다른 프로젝트를 단순히 자체 소스 트리에 포함해야 합니다. 이러한 두 선택지는 모두 생태계 전반의 유지 관리 작업을 중복하거나, 업스트림에서 새 버전을 출시할 때 포함된 코드나 복제된 노력이 자동으로 업데이트되지 않아 사용자가 보안 문제에 취약해질 가능성이 있다는 각자의 문제를 초래합니다.

특정 크로스 플랫폼 패키지 관리자를 공식적으로 권장하고 기본적으로 제공하면 이러한 서드파티 패키지를 설치하려는 사용자는 물론 이를 배포하는 사람도 더 쉽게 작업할 수 있습니다. 이제 대부분의 사용자가 적절한 설치 도구를 이용할 수 있거나 이를 얻는 방법에 대한 명확한 지침에 접근할 수 있다고 안전하게 가정할 수 있기 때문입니다. 이는 Wheel 패키지 형식이 (의도적으로) setup.py형태의 내장된 “설치 프로그램”을 제공하지 않기 때문에 향후 더욱 중요해질 것으로 예상되며, 휠 파일에서 설치하려는 사용자는 가장 간단한 경우에도 설치 프로그램을 원할 것입니다.

서드파티 패키지를 실제로 설치하는 부담을 줄이면 유용한 모든 모듈을 표준 라이브러리에 추가해야 한다는 압박도 줄어들 것입니다. 이를 통해 표준 라이브러리에 추가되는 항목은 Python이 특정 도구를 기본으로 제공해야 하는 이유와 해당 패키지가 표준 라이브러리의 18~24개월 기능 릴리스 주기를 따르는 것이 합리적인 이유에 더 집중할 수 있습니다. 서드파티 패키지 설치의 전반적인 어려움을 포함 근거로 사용하는 대신 말입니다.

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

더 광범위한 Python 패키징 생태계의 발전 지원

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

더 광범위한 커뮤니티는 Python 소프트웨어를 배포하고 설치하는 메커니즘으로 Python 패키지 색인을 받아들였지만, 언어 발전과 안전한 소프트웨어 배포에 관한 서로 다른 요구 사항을 적절히 지원하려면 이전 버전을 포괄하는 더 빠른 기능 릴리스 주기가 필요합니다.

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

이는 현재의 setup.py install 기반 패키지 설치 모델이 새로운 패키징 표준의 개발과 채택에 심각한 어려움을 초래한다는 의미입니다. 프로젝트가 setup.py 파일을 작성하는 방식에 따라 설치 명령이 다른 작업과 함께 표준 라이브러리의 distutils 패키지를 호출하게 될 수 있기 때문입니다.

이것이 더 광범위한 생태계에 문제를 일으킬 수 있음을 보여 주는 지표로, Python 2.6의 distutils 기능 집합은 2008년 6월(Python 2.6b1 릴리스 시점)에 동결되었고, Python 2.7의 distutils 기능 집합은 2010년 4월(Python 2.7b1 릴리스 시점)에 동결되었다는 점을 고려하십시오.

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

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

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

실제로 Linux 시스템에서 wget 및 curl과 같은 도구를 쉽게 사용할 수 있고, Linux에서 Python을 사용하는 대부분의 사용자가 이미 명령줄에 익숙하며, 대부분의 Linux 배포판이 Python 스크립트를 쉽게 실행할 수 있는 기본 구성을 제공한다는 사실을 고려하면, 모든 *nix 시스템에 대한 기존 pip 부트스트래핑 지침은 이미 매우 간단합니다. 시스템 패키지 관리자가 pip를 제공하지 않더라도 wget 또는 curl을 사용하여 www.pip-installer.org에서 부트스트랩 스크립트를 가져온 다음 실행하는 것은 필요할 때 쉽게 복사하여 붙여 넣을 수 있는 몇 개의 셸 명령에 불과합니다.

따라서 모든 *nix 시스템의 모든 Python 버전에서 이전 버전에 pip를 부트스트랩해야 한다는 점은 새로운 패키징 표준 채택에 대한 주요 장벽으로 간주되지 않습니다. 이러한 장기 안정 릴리스의 사용자가 겪는 작은 장애물이 하나 더 추가되는 것에 불과하기 때문입니다. *nix 시스템에서는 pip를 기본 패키징 도구로 공식적으로 권장하는 이 PEP의 입장이 pip를 기본적으로 사용할 수 있도록 만드는 데 관련된 근본적인 기술 세부 사항보다 더 중요하게 여겨집니다. 이는 pip와 pip 및 CPython의 다운스트림 재패키저 개발자 사이의 대화 성격을 바꾸기 때문입니다.

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

첫째, Python 2.6과 달리 Python 2.7은 아직 업스트림에서 완전히 지원되는 버전이며, 현재 2015년 5월로 예정된 Python 2.7.9 릴리스까지는 계속 그렇게 유지됩니다. 그 시점에 일반적인 “보안 수정만 제공” 모드로 전환될 것으로 예상됩니다. 이는 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 설치 프로그램을 사용할 수 있게 되면 별도의 PEP를 작성하여 제출할 예정입니다. 이 PEP에서는 향후 CPython 2.7 유지 관리 릴리스용 통합 설치 프로그램을 만들고 배포하는 방안을 제안하며, 해당 설치 프로그램은 CPython, pip 및 Windows용 Python Launcher 설치 프로그램을 하나의 다운로드로 결합합니다(별도의 다운로드도 계속 제공되며, 통합 설치 프로그램은 편의를 위해 제공되고 Windows 시스템에서 Python에 권장되는 운영 환경을 명확히 나타내는 역할을 합니다).

pip란 무엇입니까?

pip는 이미 널리 사용되는 도구이며 이전 도구인 easy_install의 여러 설계 및 사용자 경험 문제를 해결하므로 선호되는 기본 설치 프로그램으로 선택되었습니다(하위 호환성 문제로 인해 이러한 문제를 easy_install 자체에서 쉽게 수정할 수는 없습니다). 또한 pip는 단일 Python 런타임 설치의 범위 내에서(관련 가상 환경을 포함하여) 작동하는 데 적합하며, 이는 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의 “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 신뢰 모델에 중대한 변경을 가하지 않도록 의도적으로 선택되었습니다.

설치 프로그램에는 완전히 작동하는 Python 버전에 필요한 모든 구성 요소와 pip 설치 프로그램이 포함됩니다. 설치 과정은 네트워크 액세스를 필요로 하지 않으며, pip와 Python 패키지 색인 사이에 설정되는 네트워크 연결의 보안을 신뢰하는 데 의존하지 않습니다.

PyPI와 통신하기 위해 pip를 사용하기로 선택한 사용자만 그러한 사용에 수반되는 추가 보안 고려 사항에 주의를 기울여야 합니다.

그러나 핵심 CPython 팀은 현재 requests 프로젝트(따라서 pip)에 영향을 미치는 최소한 인증서 업데이트 관리 문제를 검토하고 해결하는 작업을 계속 지원하며, 확인된 다른 보안 우려 사항을 해결하는 데도 도움을 제공할 수 있습니다 [1].

신뢰성 고려 사항

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

구현 전략

Python을 설치하거나 가상 환경을 생성할 때 네트워크 액세스가 필요하지 않도록 하기 위해, ensurepip 모듈은 구현 세부 사항으로 pip와 그 의존성의 완전한 비공개 사본을 포함하며, 이를 사용하여 pip를 추출하고 대상 환경에 설치합니다. 이 pip의 비공개 사본은 오직 구현 세부 사항일 뿐이며, ensurepip 모듈을 통해 공개된 기능(및 간접적으로 venv를 통해 공개된 기능)을 넘어 존재한다고 의존하거나 가정해서는 안 됩니다.

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

부트스트래핑을 처리하기 위한 별도의 코드를 포함하는 대신, ensurepip 모듈은 sys.path를 적절히 조작하여 휠 파일을 사용해 휠 파일 자체를 설치할 수 있도록 하며, 이는 현재 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 인증서 관리 문제를 해결합니다.
    • pip 1.5 최종 릴리스 또는 후속 유지 보수 릴리스로 ensurepip를 업데이트합니다(적절히 업데이트된 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.

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

  • 설치 중 “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가 이미 설치되어 있으면 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 패키지를 계속 사용하기로 선택했습니다. 이 패키지는 does 기본적으로 설치된 pip를 포함합니다.

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의 표준 라이브러리 문서에서 “Installing Python Modules” 절이 pip 설치 프로그램 사용을 권장하도록 업데이트됩니다. Python 3.4에서는 기본적으로 제공되고, Python 2.7 또는 3.3에서는 사용자가 가져와 설치해야 합니다. 가장 일반적인 명령과 옵션을 간략히 설명하지만, 전체 세부 사항은 외부에서 유지 관리되는 pip 문서로 위임합니다.

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

모듈 설치 안내서의 기존 내용은 모든 버전에서 유지되지만, “Invoking distutils directly”라는 새 하위 절 아래에 배치됩니다.

CPython에 CA 인증서 포함하기

ensurepip 구현에는 나머지 pip와 함께 pip CA 번들이 포함됩니다. 이는 CPython이 추출된 후 오로지 pip에서 사용되는 CA 번들을 사실상 포함한다는 의미입니다.

이는 시스템 인증서 저장소에만 의존하는 것보다 바람직한 것으로 간주됩니다. 지원되는 모든 Python 버전에서 pip가 동일하게 동작하도록 보장하기 때문이며, 여기에는 Windows에서 시스템 인증서 저장소에 액세스할 수 없는 Python 3.4 이전 버전도 포함됩니다.

setuptools 자동 설치

pip는 현재 빌드 과정에서 메타데이터 생성을 처리하고 일부 다른 기능을 지원하기 위해 setuptools에 의존합니다. 이 종속성을 줄이거나 제거하기 위한 작업이 진행 중이지만, Python 3.4.0 출시 시점에 현재 버전일 가능성이 높은 pip 1.5에서 해당 작업이 완료될지는 분명하지 않습니다.

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

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

setuptools의 비공개 사본은 더 이상 필요하지 않게 되면 ensurepip에서 제거합니다. 이는 get-pip.py가 기본적으로 setuptools를 설치하지 않게 되는 시점일 가능성이 높습니다. setuptools가 필요한 동안에는 최신 업스트림 setuptools 릴리스의 완전히 수정되지 않은 사본을 사용하며, 업스트림 setuptools가 계속 포함하는 경우 easy_install스크립트도 포함합니다. easy_install을 pip와 함께 설치하는 것은 바람직하지 않다고 간주하지만, 손상된 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 수정 옵션이 활성화된 경우 Python 3.4 이상에서 Windows 설치 프로그램이 sysconfig.get_path("scripts")가 반환하는 경로도 Windows PATH에 추가하도록 업데이트할 것을 제안합니다

이 변경 사항은 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에서 pyvenv 명령을 훨씬 쉽게 호출할 수 있게 되며, pip, easy_install 및 유사한 도구가 설치하는 모든 스크립트도 마찬가지입니다.

최신 Python 버전에서 스크립트를 호출하면 Windows용 Python 런처를 통해 실행되지만, Scripts 디렉터리의 Python 파일이 셰뱅 줄에 Python 버전을 올바르게 지정하거나 인접한 Windows 실행 파일을 가지고 있다면(easy_install 및 pip가 그러함) 문제가 발생하지 않습니다.

다운스트림 배포자에 대한 권장 사항

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 패키지 설치를 권장하는 일종의 전역 후크가 있도록 하는 것입니다. 이 옵션을 선택하는 시스템은 가상 환경 내부에서 호출될 때 ensurepip 모듈이 여전히 pip를 직접 설치하도록 해야 하지만, 시스템 Python 설치의 모듈을 수정하여 pip를 전역으로 설치할 때 플랫폼이 제공하는 메커니즘으로 리디렉션할 수 있습니다.
  • 다른 수단으로 pip를 전역에서 사용할 수 있게 하더라도 Python 3.4 이상에서는 ensurepip 모듈을 제거하지 마십시오.
    • venv 모듈이 가상 환경에 pip를 자동으로 설치하려면 ensurepip가 필요합니다.
    • 이는 기존 virtualenv 패키지와 유사하며, 많은 다운스트림 배포자가 이미 일반적인 “번들 해제” 정책에 예외를 적용하고 있습니다.
    • 이는 보안 문제로 인해 pip를 업데이트해야 하는 경우 ensurepip 부트스트랩 모듈의 비공개 복사본도 업데이트해야 한다는 의미입니다
    • 그러나 내장된 CA 인증서 번들을 제거하고 대신 시스템 CA 번들에 의존하도록 pip의 비공개 복사본을 변경하는 것은 합리적인 변경입니다.
  • 재배포된 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는 서드파티 패키지를 사용하려는 최종 사용자의 부담을 줄이는 것을 목표로 하며, 그 안의 결정은 Python 커뮤니티가 이미 pip, setuptools, PyPI, virtualenv 및 기타 관련 프로젝트의 작성자이자 유지 관리자인 Python Packaging Authority에 부여한 신뢰를 반영하는 실용적인 결정입니다.

하위 호환성

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

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

보안 릴리스

ensurepip 모듈에 영향을 미치는 모든 보안 업데이트는 릴리스 전에 Python Security Response Team(security@python.org)과 공유됩니다. 그런 다음 PSRT는 보고된 문제가 업데이트된 pip의 비공개 복사본을 포함한 CPython 보안 릴리스를 보장하는지 결정합니다.

라이선스

pip은 현재 1 Clause BSD로 라이선스가 부여되어 있으며, 다른 프로젝트에서 가져온 코드가 포함되어 있습니다. 또한 이 PEP에는 pip가 더 이상 setuptools를 필요로 하지 않게 될 때까지 setuptools가 포함됩니다. 이러한 라이선스는 아래 표에 나와 있습니다.

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

이러한 모든 라이선스는 PSF 라이선스와 호환되어야 합니다. 또한 CA Bundle이 저작권 보호 대상 자료인지, 따라서 라이선스가 필요하거나 라이선스를 부여할 수 있는지조차 불분명합니다.

부록: 거부된 제안

Windows에서 scripts 디렉터리의 이름 변경

이 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를 제공하자는 제안은 보편적으로 인기가 있었지만, 이 제안의 이 부분은 논란이 매우 컸으며 결국 MvL에 의해 BDFL-Delegate로서 거부되었습니다.

이에 따라 ensurepip를 Python 2.7 및 3.3에 백포트하자는 제안은 이 PEP에서 삭제되었으며, 그 대신 pip용 Windows 설치 프로그램과 CPython 2.7, pip 및 Windows용 Python Launcher를 결합하는 Python 2.7용 통합 설치 프로그램의 생성을 제안하는 향후 PEP를 작성하는 방안이 채택되었습니다.

pip를 부트스트랩할 때 PyPI에 자동으로 연락하기

이 PEP의 이전 버전에서는 부트스트랩 모듈을 getpip라고 명명했으며, 기본적으로 PyPI에서 pip를 다운로드하여 설치하고 비공개 사본은 대체 수단으로 사용하거나 명시적으로 요청한 경우에만 사용하도록 했습니다.

이로 인해 여러 복잡한 경계 사례가 발생했으며, 부트스트랩 모듈을 위한 깔끔한 API와 CLI를 정의하는 데에도 어려움이 있었습니다. 또한 python.org에 게시된 바이너리 설치 프로그램의 기본 신뢰 모델도 크게 변경되었습니다. 설치 후 pip를 명시적으로 호출하여 PyPI 생태계의 보안을 신뢰하도록 선택하는 대신, 최종 사용자가 이를 신뢰하지 않도록 명시적으로 opt-out해야 했기 때문입니다.

그 결과, 부트스트래핑이 항상 pip의 비공개 복사본을 사용하는 현재 설계로 PEP가 단순화되었습니다. 이제 PyPI에 접속하는 작업은 전체 pip 인터페이스에 직접 액세스하는 명시적인 별도 단계입니다.

PyPI에 암시적으로 액세스하려는 시도를 제거함으로써, 사용자 지정 소스 빌드에서 설치할 때 기본적으로 ensurepip을 호출할 수 있게 되었습니다.

암시적 부트스트랩

이 PEP의 전신인 PEP 439는 자체적인 해결책을 제안합니다. 이 솔루션은 실행 시 pip가 아직 존재하지 않는 경우 이를 암묵적으로 부트스트랩하고 설치하는 가짜 pip 명령을 제공하는 방식입니다. 이는 너무 “마법적”이기 때문에 거부되었습니다. 이 방식은 pip 명령이 정확히 언제 설치되는지 또는 애초에 설치되고 있는지 최종 사용자에게 알리지 않습니다. 또한 시스템에 일반적인 메커니즘을 통해 전역으로 설치된 pip를 관리하려는 다운스트림 패키저를 위한 권장 사항이나 고려 사항도 제공하지 않습니다.

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

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

이 PEP와 유사한 제안으로 pip를 표준 라이브러리에 포함하자는 것이 있습니다. 이렇게 하면 Python에 항상 pip가 포함되도록 보장하고, 기본적으로 pip가 설치되어 있지 않아 발생하는 최종 사용자 측의 모든 문제를 해결할 수 있습니다. 그러나 표준 라이브러리에 distutils를 포함하고 유지해 온 역사에서, 패키징 도구를 독립적으로 업데이트할 수 있는 능력을 잃으면 도구가 끊임없는 림보 상태에 놓일 수 있다는 사실을 배웠기 때문에 이는 거부되었습니다. 그 결과 사용자에게 실제로 영향을 미치는 기간 내에 합리적으로 발전할 수 없게 되며, 새로운 기능이 일반 사용자에게 제공되기까지 수년이 걸리게 됩니다.

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

프로젝트가 외부에서 계속 유지 관리되면서 또한 표준 라이브러리에서 유지 관리되는 포크를 보유하는 경우, “dual maintenance” 문제와 관련된 문제가 과거에도 있었습니다. 이전 Python 버전을 지원하려면 pip의 외부 유지 관리가 항상 필요하므로, 제안된 부트스트래핑 메커니즘은 CPython 핵심 개발자의 명시적인 책임이 되며(pip 개발자의 지원을 받음), CPython 추적기에 보고된 pip 문제는 pip 이슈 추적기로 이전됩니다. 어느 추적기를 사용해야 하는지에 대해 일부 사용자가 여전히 혼란을 겪을 것은 분명하지만, 표준 라이브러리에 서드파티 프로젝트의 완전한 공개 복사본을 포함했을 때 역사적으로 보였던 혼란보다는 적기를 바랍니다.

이 PEP에서 설명하는 접근 방식은 pip가 독립적으로 더 최신 버전으로 업데이트된 경우 CPython 유지 관리 업데이트를 처리하는 것과 관련된 일부 기술적 문제도 방지합니다. 제안된 pip 기반 부트스트래핑 메커니즘은 이를 자동으로 처리합니다. pip와 시스템 설치 프로그램이 pip 설치를 누가 소유하는지를 두고 충돌하는 일이 결코 발생하지 않기 때문입니다(ensurepip부트스트랩 모듈을 통해 직접 또는 간접적으로 항상 pip가 관리합니다).

마지막으로, 별도의 부트스트래핑 단계가 있으므로 최종 사용자가 원하는 경우 pip를 전혀 설치하지 않도록 하기도 쉽습니다. 통합자가 공통 도구 집합을 사용하여 여러 언어로 작성된 구성 요소의 설치를 시스템 패키지로 처리하는 경우에 이러한 일이 흔히 발생합니다.

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

기본적으로 사용자별 site-packages 디렉터리에 pip를 부트스트랩하는 방안도 일부 고려되었습니다. 그러나 이 동작은 pip 자체의 기본 동작과 다르므로 놀라울 수 있으며, 현재로서는 신뢰할 수 있는 것으로 간주되지도 않습니다(시스템 site-packages 디렉터리가 아닌 사용자 site-packages 디렉터리에 pip를 설치할 때 올바르게 처리되지 않는 일부 예외적인 경우가 있습니다).

참고 자료