PEP 470 – PyPI에서 외부 호스팅 지원 제거

Author:

Donald Stufft <donald at stufft.io>

BDFL-Delegate:

Paul Moore <p.f.moore at gmail.com>

Discussions-To:

Distutils-SIG list

Status:

Final

Type:

Process

Topic:

Packaging

Created:

12-May-2014

Post-History:

14-May-2014, 05-Jun-2014, 03-Oct-2014, 13-Oct-2014, 26-Aug-2015

Replaces:

438

Resolution:

Distutils-SIG message

---

Table of Contents

• 초록
• 근거
  • 주요 사용자 경험 기대 사항
  • 추가 저장소가 필요한 이유
  • PEP 438 또는 유사한 방식은 왜 사용하지 않는가?
• 여러 저장소/색인 지원
• 링크 스파이더링의 폐기 및 제거
• 변경 사항 요약
  • 저장소 측
  • 클라이언트 측
• 영향
• 자주 묻는 질문
  • <X> 때문에 PyPI에서 프로젝트를 호스팅할 수 없습니다. 어떻게 해야 합니까?
  • 이 PEP 때문에 사용자의 경험이 이전보다 나빠졌는데, 이를 어떻게 설명해야 합니까?
  • 저장소 구조로 전환하면 작업 흐름이 중단되거나 호스트에서 이를 허용하지 않습니까?
  • 왜 <X>를 제공하지 않습니까?
  • 어차피 자체 저장소를 운영하고 있다면 왜 PyPI에 등록해야 합니까?
• 거부된 제안
  • 외부에서 호스팅되는 색인을 더 쉽게 발견하도록 허용
  • 현재 분류 시스템을 유지하되 옵션을 조정
  • 이 PEP를 구현하되, 기존 링크는 제거하지 않기
• Copyright

번역·라이선스 안내

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

초록

이 PEP는 PyPI 외부에서 파일을 호스팅하는 지원의 폐지 및 제거와 함께, PEP 438에서 추가된 기능, 특히 다양한 링크 유형을 분류하기 위한 rel 정보와 API 버전을 나타내는 메타 태그의 폐지 및 제거를 제안합니다.

근거

역사적으로 PyPI에는 파일을 호스팅하거나 설치 가능한 파일을 자동으로 검색하는 방법이 없었으며, 이름 충돌을 방지하기 위한 중앙 이름 레지스트리와 사용할 프로젝트를 찾기 위한 검색 수단을 제공하는 데 중점을 두었습니다. 시간이 지나면서 setuptools는 이러한 사용자 대상 페이지와 해당 페이지에서 링크된 페이지를 크롤링하기 시작했으며, 자동으로 다운로드하고 설치할 수 있는 항목을 찾았습니다. 결국 이는 유사한 URL 구조를 사용하지만 API의 효율성을 높이기 위해 불필요한 링크와 정보를 제거한 “Simple” API가 되었습니다. 또한 PyPI는 프로젝트가 릴리스 파일을 PyPI에 직접 업로드할 수 있는 기능을 갖추게 되었으며, 이를 통해 PyPI는 색인인 동시에 저장소로도 기능할 수 있게 되었습니다.

이를 통해 PyPI는 Python 생태계에서 똑같이 중요한 두 가지 역할, 즉 Python 프로젝트를 쉽게 검색할 수 있도록 하는 색인과 Python 프로젝트를 쉽게 호스팅하고 다운로드하며 설치할 수 있도록 하는 중앙 저장소를 수행하게 되었습니다. PyPI의 역사와 매우 유기적으로 이루어진 성장으로 인해 이 두 역할 사이의 경계는 모호하며, 이러한 모호함은 두 역할의 최종 사용자에게 혼란을 일으켰습니다. 또한 이는 서로 다른 방식으로 PyPI를 사용하려는 사람들 사이에 불만을 초래했으며, 특히 최종 사용자는 PyPI를 저장소로 사용하려 하는 반면 작성자는 PyPI를 오로지 색인으로만 사용하려 할 때 그러했습니다.

이러한 혼란은 프로젝트의 최종 사용자가 해당 프로젝트가 PyPI에서 호스팅되는지, 아니면 외부 서비스에 의존하는지를 파악하지 못하는 데서 비롯됩니다. 외부 서비스는 중단되었지만 PyPI는 중단되지 않았을 때 이러한 상황이 자주 나타납니다. 사람들은 PyPI와 다른 프로젝트들은 작동하는데 특정 프로젝트 하나만 작동하지 않는 것을 보게 됩니다. 이 문제를 해결하려면 누구에게 연락해야 하는지 또는 어떤 복구 절차를 따라야 하는지 모르는 경우가 많습니다.

PEP 438은 프로젝트가 저장소 기능을 사용하는지 여부를 명시적으로 선언할 수 있도록 하여 이 문제를 해결하려 했으며, 사용하지 않는 경우 설치 도구가 발견한 링크를 “internal”, “verifiable external” 또는 “unverifiable external”로 분류하도록 했습니다. PEP 438은 2013년 7월 23일에 출시된 pip 1.4에서 승인되고 구현되었으며, 최종 전환은 2014년 1월 2일에 출시된 pip 1.5에서 구현되었습니다.

PEP 438은 PyPI의 저장소 기능을 활용하는 사람을 더 많이 이끌어 내는 데 성공했으며, PyPI를 구동하는 전 세계 CDN이 많은 사람에게 속도 향상을 제공한다는 점에서 이는 전반적으로 좋은 일이었습니다. 그러나 최종 사용자와 작성자 모두에게 새로운 혼란과 고충을 야기하기도 했습니다.

명시적인 여러 저장소를 사용하는 방식으로 전환하면 이 두 역할 사이의 경계를 훨씬 더 명확히 하고, PyPI를 저장소로 사용하지 않으려는 사람들을 처리하는 현재 구현으로 인해 발생하는 “숨겨진” 의외의 상황을 제거할 수 있습니다.

주요 사용자 경험 기대 사항

1. 시스템, 사용자 또는 가상 환경 수준에서 적절히 구성되었을 때 외부 호스팅이 “그냥 작동하도록” 쉽게 허용합니다.
2. 설치할 때와 패키지를 릴리스할 때 모두 사용자 경험에서 혼란을 일으키는 “verifiable external”과 “unverifiable external”의 구분에 관한 모든 참조를 제거합니다.
3. PyPI의 저장소 기능은 단지 기본 패키지 호스팅 위치가 되어야 합니다(즉, 대부분의 클라이언트 도구가 기본 구성에서 옵트인이 아닌 옵트아웃으로 취급하는 유일한 위치가 되어야 합니다). 이 측면을 제외하면 PyPI에서 호스팅하는 것이 자체 패키지 저장소를 호스팅하는 것보다 더 향상된 사용자 경험을 제공해서는 안 됩니다.
4. 위의 모든 사항을 수행하면서 국가 수준의 공격자보다 낮은 수준에 있는 대부분의 공격자에 대해 안전한 기본 동작을 제공합니다.

추가 저장소가 필요한 이유

pip와 easy_install/setuptools라는 두 가지 일반적인 설치 도구는 모두 설치 요구 사항을 충족하는 파일을 검색할 추가 위치라는 개념을 지원하며, 수년 동안 이를 지원해 왔습니다. 따라서 새로운 플래그나 개념을 “단계적으로” 도입할 필요가 없으며, PyPI 이외의 저장소에서 프로젝트를 설치하는 해결책은 최종 사용자의 설치 도구가 얼마나 오래되었는지(합리적인 범위 내에서)와 관계없이 작동합니다. 이 개념은 Python 도구에 한동안 존재해 왔을 뿐만 아니라 여러 언어에 걸쳐 존재하며, OS 수준으로까지 확장되어 OS 패키지 도구가 거의 보편적으로 여러 저장소를 지원하므로 누군가 이미 이 개념에 익숙할 가능성이 매우 높습니다.

또한 여러 저장소 접근 방식은 PyPI의 색인 부분에는 포함되기를 원하지만 저장소 부분은 사용하지 않으려는 프로젝트를 허용한다는 좁은 범위를 넘어 유용한 개념입니다. 여기에는 회사가 내부 패키지를 포함하는 저장소를 호스팅하려는 경우나, 프로젝트가 알파, 베타, 릴리스 후보, 최종 릴리스와 같이 여러 릴리스 “채널”을 두려는 경우가 포함됩니다. 또한 수 기가바이트 크기의 데이터 파일이나, 적어도 현재로서는 Linux Wheels처럼 PyPI에 업로드할 수 없는 파일을 호스팅하려는 프로젝트에도 이를 사용할 수 있습니다.

PEP 438 또는 유사한 방식은 왜 사용하지 않는가?

추가 검색 위치 지원은 pip와 setuptools에 꽤 오래전부터 존재했지만, PEP 438 지원은 pip의 1.4 버전부터만 존재했으며 setuptools에는 아직 구현되지 않았습니다. 사용자들은 외부 파일이 필요하지 않은 프로젝트의 경우 이전 설치 프로그램을 사용하더라도 PEP 438의 설계 덕분에 여전히 혜택을 받았지만, 실제로 외부 파일이 필요한 프로젝트의 경우에는 잠재적으로 신뢰할 수 없거나, 더 나쁘게는 안전하지 않은 파일을 다운로드하도록 여전히 사용자에게 알림 없이 제공하고 있습니다. 이 시스템은 PyPI의 역사에서 비롯되었기 때문에 Python에만 존재하는 독특한 시스템입니다. 따라서 대부분의 사용자, 아니 거의 모든 사용자는 Python 도구 모음을 사용하려다 이 개념을 접하기 전까지는 이 개념이 생소할 것이 거의 확실합니다.

또한 PEP 438에서 제안한 분류 시스템은 실제로 최종 사용자에게 매우 혼란스러운 것으로 드러났으며, 그 정도가 매우 심하여 현재 상황은 완전히 지속 불가능하다는 것이 이 PEP의 입장입니다. 이 시스템을 사용하는 일반적인 사용 패턴은 프로젝트를 설치하려고 시도하고, 오류 메시지를 받을 수도 있으며(프로젝트가 PyPI에 무언가를 업로드했다가 이전 파일을 제거하지 않고 나중에 방식을 변경했다면 오류 메시지를 받지 않을 수도 있습니다), 오류 메시지에서 --allow-external을 제안하는 것을 확인한 다음, 해당 플래그를 추가하여 명령을 다시 실행하고 대개 또 다른 오류 메시지를 받으며, 이번에는 오류 메시지에서 --allow-unverified도 추가하라고 제안하는 것을 확인한 뒤, 명령을 다시 세 번째로 실행하여 마침내 설치하려던 항목을 얻는 것입니다.

이러한 UX 실패에는 몇 가지 이유가 있습니다.

1. pip가 Simple API에서 프로젝트의 파일을 하나라도 찾을 수 있다면 더 많은 파일을 찾으려 하지 않고 단순히 해당 파일을 사용합니다. 더 많은 파일을 찾으려는 시도는 PEP 438의 이점 중 상당 부분을 없애게 되므로, 이는 일반적으로 올바른 동작입니다. 이는 프로젝트가 사용자가 설치를 요청한 것과 일치하는 파일을 언젠가 업로드했다면, 그 파일이 얼마나 오래되었는지와 관계없이 사용된다는 의미입니다.
2. PEP 438은 대부분의 프로젝트가 PyPI에 직접 업로드하거나 릴리스 파일로 직접 연결하도록 스스로 변경할 것이라고 암묵적으로 가정합니다. 많은 프로젝트가 결국 PyPI에 업로드하기로 결정했지만, 그중 일부는 PEP 438을 둘러싼 UX가 너무 형편없어서 어쩔 수 없이 그렇게 했다고 느꼈기 때문에 업로드했습니다. 그러나 더욱 우려스러운 사실은 파일에 직접적이고 안전하게 연결하기로 선택한 프로젝트가 극히 적다는 점입니다. 대신 이들은 실제 파일을 찾기 위해 스크레이핑해야 하는 페이지에 여전히 단순히 연결하고 있으며, 그 결과 안전한 변형인 --allow-external은 대부분 쓸모없게 되었습니다.
3. 작성자가 자신의 파일에 직접 연결하고 싶어 하더라도 이를 안전하게 수행하는 방법은 명확하지 않습니다. 이를 위해서는 역사적인 이유로 URL의 해시에 MD5 해시를 포함해야 합니다. 이를 포함하지 않으면 해당 파일은 “unverified”로 간주됩니다.
4. PEP 438은 보안을 중심으로 접근하여 검증되지 않은 프로젝트에 대한 전역적인 옵트인을 어떤 형태로든 허용하지 않습니다. 이는 일반적으로 좋은 일이지만, 다음과 같이 매우 장황하고 반복적인 명령 실행을 초래합니다.:

   $ pip install --allow-external myproject --allow-unverified myproject myproject
   $ pip install --allow-all-external --allow-unverified myproject myproject
   

여러 저장소/색인 지원

설치 프로그램은 설치 프로그램이 여러 URL 위치를 가리킬 수 있는 기능을 구현하거나 계속 제공해야 합니다. 사용자가 추가 위치를 사용하고 싶다는 의사를 표시하는 정확한 메커니즘은 각 구현에 맡깁니다.

또한 여러 저장소를 사용할 때 설치 후보를 검색하는 메커니즘 역시 각 구현에 맡기지만, 일단 구성된 구현은 어떤 저장소가 기본 저장소가 아니라는 이유만으로 해당 저장소의 사용을 만류하거나 경고하거나 그 밖의 방식으로 부정적으로 묘사해서는 안 됩니다.

현재 pip와 setuptools는 두 저장소 중 어디에서든 찾을 수 있는 최적의 설치 후보를 사용하여 여러 저장소를 지원하며, 기본적으로 이를 하나의 큰 저장소인 것처럼 취급합니다.

설치 프로그램은 기본 저장소의 사용을 제거하거나 그 밖의 방식으로 비활성화할 수 있는 메커니즘도 구현해야 합니다. 이를 달성하는 방법의 구체적인 세부 사항은 각 구현에 맡깁니다.

설치 프로그램은 사용자가 특정 저장소에서 설치하려는 프로젝트를 허용 목록과 차단 목록으로 관리할 수 있는 메커니즘도 구현해야 합니다. 이를 달성하는 방법의 구체적인 세부 사항은 각 구현에 맡깁니다.

Python packaging guide 문서는 자체 저장소를 설정하는 방법을 설명하는 섹션을 포함하도록 업데이트되어야 하며, 이를 통해 향후 PyPI에서 호스팅하지 않으려는 모든 프로젝트가 해당 문서를 참조할 수 있어야 합니다. 여기에는 자체 저장소 호스팅에 의존하는 프로젝트가 프로젝트 설명에 프로젝트 설치 방법을 문서화해야 한다는 제안이 포함되어야 합니다.

링크 스파이더링의 폐기 및 제거

PyPI에 새로운 호스팅 모드가 추가됩니다. 이 호스팅 모드는 pypi-only라고 하며, PEP 438에서 이미 제공한 pypi-explicit, pypi-scrape, pypi-scrape-crawl이라는 세 가지 호스팅 모드에 추가됩니다. 이 새로운 호스팅 모드는 프로젝트의 Simple API 페이지를 수정하여 PyPI에서 직접 호스팅되는 파일만 나열하고 다른 어떤 항목에도 연결하지 않도록 합니다.

이 PEP가 승인되고 pypi-only 모드가 추가되면 모든 새 프로젝트는 기본적으로 PyPI 전용 모드로 설정되며, 이 모드로 잠겨 해당 설정을 변경할 수 없게 됩니다.

이후 PyPI에서만 호스팅되는 모든 프로젝트에 이메일을 보내 한 달 후 프로젝트가 자동으로 pypi-only 모드로 변환된다는 사실을 알립니다. 이러한 이메일을 보낸 후 한 달이 지나면, 이메일을 받은 프로젝트 중 여전히 PyPI에서만 호스팅되는 프로젝트의 모드가 영구적으로 pypi-only로 설정됩니다.

동시에 PyPI 외부의 호스팅에 의존하는 프로젝트에도 이메일을 보냅니다. 이 이메일에서는 외부에서 호스팅되는 파일이 PyPI에서 더 이상 사용되지 않으며, 이메일 발송 시점으로부터 3개월 후 모든 외부 링크가 설치 프로그램 API에서 제거된다는 사실을 해당 프로젝트에 알립니다. 이 이메일에는 프로젝트를 PyPI에서 호스팅하도록 변환하는 지침이 MUST 포함되어야 하며, PyPI 자격 증명과 패키지 이름을 입력하면 모든 파일을 자동으로 다운로드하여 PyPI에서 다시 호스팅할 수 있게 해 주는 스크립트 또는 패키지로 연결되는 링크가 MUST 포함되어야 합니다. 이 이메일에는 자체 색인 페이지를 설정하는 지침도 MUST 포함되어야 합니다. 많은 사용자가 오래전에 가입하여 해당 약관이 무엇인지 기억하지 못할 수 있으므로, 이 이메일에는 PyPI 서비스 약관으로 연결되는 링크도 포함되어야 합니다. 마지막으로 이 이메일에는 PyPI에 등록된 링크 중 설치 가능한 파일이 있는 것으로 감지된 링크의 목록도 포함되어야 합니다.

최초 이메일을 보낸 후 두 달이 지나면 외부 호스팅에 여전히 의존하는 모든 프로젝트에 또 다른 이메일을 보내야 합니다. 이 이메일에는 최초 이메일에 포함된 것과 동일한 모든 정보가 포함되지만, 제거 날짜는 3개월 후가 아니라 한 달 후가 됩니다.

마지막으로 한 달 후 모든 프로젝트를 pypi-only 모드로 전환하고, PyPI를 수정하여 외부 링크 파일 기능을 제거합니다.

변경 사항 요약

저장소 측

1. 관련 PEP 438에 정의된 호스팅 모드를 폐기 예정으로 지정하고 제거합니다.
2. 단순 API가 저장소 내부에 포함된 파일만 나열하도록 제한합니다.

클라이언트 측

1. 여러 저장소 지원을 구현합니다.
2. 기본 저장소를 제거하거나 비활성화할 수 있는 메커니즘을 구현합니다.
3. 지원 중단 / 제거 대상: PEP 438

영향

영향을 판단하기 위해 pip 및 setuptools와 유사한 방식으로 PyPI를 검색하는 방법을 사용하여 모든 프로젝트를 살펴보고, PyPI에서 사용 가능한 모든 파일, PyPI에서 안전하게 연결된 파일, PyPI에서 안전하지 않게 연결된 파일, 마지막으로 PyPI 외부에서 안전하지 않게 사용 가능한 모든 파일을 검색했습니다. 동일한 파일이 여러 위치에서 발견된 경우 다음 우선순위에 따라 중복을 제거하고 한 위치에서만 집계했습니다: PyPI > PyPI 외부 안전 호스팅 > PyPI 외부 비안전 호스팅. 이는 영향에 대한 가장 포괄적인 정의를 제공합니다. 즉, 이 프로젝트의 특정 파일 하나가 더 이상 기본적으로 표시되지 않을 수 있지만, 해당 파일은 수년 전에 만들어진 파일일 수도 있고 PyPI에 sdist가 제공되는 동안의 바이너리 파일일 수도 있습니다. 따라서 실제 영향은 훨씬 작을 가능성이 높지만, 잘못 집계하지 않기 위해 가장 포괄적인 정의를 사용합니다.

이 글을 작성하는 시점에 PyPI에서 호스팅되는 프로젝트는 65,232개이며, 그중 59개는 PyPI 외부에서 안전하게 호스팅되는 외부 파일에 의존하고 931개는 PyPI 외부에서 안전하지 않게 호스팅되는 외부 파일에 의존합니다. 이는 프로젝트의 1.5%가 어떤 방식으로든 이 변경의 영향을 받는 반면 98.5%는 지금까지와 마찬가지로 계속 작동한다는 것을 보여 줍니다. 또한 영향을 받는 프로젝트 중 5%만 PEP 438에서 제공하는 기능을 사용하여 PyPI 외부에서 안전하게 호스팅하고 있으며, 나머지 95%는 중간자 공격을 통한 원격 코드 실행에 사용자를 노출하고 있습니다.

자주 묻는 질문

<X> 때문에 PyPI에서 프로젝트를 호스팅할 수 없습니다. 어떻게 해야 합니까?

먼저 <X>가 PyPI에 본질적인 것인지, 아니면 PyPI가 기능을 추가하여 <X>를 대신 해결할 수 있는지 결정해야 합니다. PyPI가 프로젝트를 PyPI에서 호스팅할 수 있도록 기능을 추가할 수 있다면 해당 기능을 제안해야 합니다. 그러나 <X>가 PyPI에 본질적인 것, 예를 들어 자체 파일에 대한 통제권을 유지하려는 것이라면, 자체 패키지 저장소를 설정하고 프로젝트 설명에서 사용자가 선택한 설치 프로그램이 사용할 저장소 목록에 해당 저장소를 추가하도록 안내해야 합니다.

이 PEP 때문에 사용자의 경험이 이전보다 나빠졌는데, 이를 어떻게 설명해야 합니까?

이 답변의 일부는 각 개별 프로젝트에 따라 달라지므로, 이미 설치 프로그램의 기본 저장소 목록에 있는 저장소를 이용하지 않고 자체 저장소에서 호스팅하기로 결정한 이유를 사용자에게 설명해야 합니다. 그러나 이 답변에서는 외부 링크를 투명하게 포함하던 이전 동작이 보안 위험이자 안정성 문제였다는 점도 설명해야 합니다. 대부분의 경우 이 동작으로 인해 MITM이 최종 사용자의 컴퓨터에서 임의의 Python 코드를 실행할 수 있었기 때문입니다. 또한 PEP 438은 사용자가 이를 명시적으로 선택하도록 만들어 이 문제를 해결하려 했지만, PEP 438은 심각한 사용성 문제를 여러 가지 수반했습니다. PEP 470은 Linux 배포판에서 흔히 사용되며 많은 사용자에게 익숙한 모델과 유사한, 더 단순화된 모델을 제시합니다.

저장소 구조로 전환하면 작업 흐름이 중단되거나 호스트에서 이를 허용하지 않습니까?

저장소에 필요한 사항을 기꺼이 지원할 저렴하거나 무료인 호스트가 여러 곳 있습니다. 특히 실제 파일이 있는 위치를 가리키는 올바른 구조의 호스트를 생성할 수만 있다면, 파일을 다른 곳에 업로드할 필요가 없습니다. 이러한 호스트 중 다수는 공유 도메인 이름을 사용하여 무료 HTTPS를 제공하며, 무료 HTTPS 인증서는 StartSSL 또는 가까운 시일 내에는 LetsEncrypt에서 받을 수 있고, 여러 제공업체에서 저렴하게 구할 수도 있습니다.

왜 <X>를 제공하지 않습니까?

여기서 답변은 <X>가 무엇인지에 따라 달라지지만, 일반적으로 답변은 다음 중 하나입니다.

• 저희가 그것을 생각해 본 적이 없고 이전에 아무도 제안하지 않았습니다.
• 저희는 <X>에 대한 해결책을 적절히 설계할 경험이 충분하지 않으며, 해당 분야 전문가가 이를 제공하는 데 도움을 주신다면 환영하겠습니다.
• 저희는 오픈 소스 프로젝트이며, 아직 <X>를 설계하고 구현하겠다고 자원한 사람이 없습니다.

추가 기능을 제안하는 추가 PEP는 언제나 환영하지만, <X>를 정확하게 설계할 시간과 전문 지식을 가진 사람이 필요합니다. 이 PEP는 Linux 배포판 저장소와 같은 기존 모델과 유사하면서도 쉽게 이해할 수 있는 기준에 따라 PyPI의 기능을 명확하게 사용할 수 있는 지점에 도달하는 데 초점을 맞추고 있습니다.

어차피 자체 저장소를 운영하고 있다면 왜 PyPI에 등록해야 합니까?

PyPI는 Python 생태계에서 두 가지 중요한 기능을 제공합니다. 그중 하나는 pip 또는 다른 패키지 관리자가 다운로드하고 설치하는 실제 파일을 위한 중앙 저장소이며, 이 PEP가 다루는 기능이자 자체 저장소를 운영할 경우 대체하게 되는 기능입니다. 그러나 PyPI는 이름 충돌을 방지하기 위해 어떤 이름을 누가 소유하는지에 대한 중앙 레지스트리도 제공합니다. Python 패키지를 위한 DNS와 비슷한 것이라고 생각하면 됩니다. 이름이 선착순으로 배정되도록 하는 것뿐만 아니라, 사용자가 새로운 프로젝트를 찾아보고 검색하고 발견할 수 있는 단일 장소도 제공합니다. 따라서 간단히 답하면, 이름 충돌을 방지하고 사람들이 프로젝트를 계속 쉽게 발견할 수 있도록 프로젝트를 PyPI에 등록해야 합니다.

거부된 제안

외부에서 호스팅되는 색인을 더 쉽게 발견하도록 허용

이 PEP의 이전 버전에는 PyPI와 설치 프로그램 양쪽에 추가되는 새로운 기능이 포함되어 있었습니다. 이 기능을 사용하면 프로젝트 작성자가 PyPI에 URL 목록을 입력하고, 설치 프로그램이 PyPI에 업로드된 모든 파일을 무시하는 대신 최종 사용자에게 설치 프로그램에 추가하여 설치가 작동하도록 할 수 있는 추가 URL을 알려 주는 오류를 반환하도록 할 수 있었습니다.

이 기능은 PEP 438의 해결책에서 발생한 수많은 문제와 유사한 UX 문제를 피하는 해결책을 개발하기가 지나치게 어려운 것으로 드러났기 때문에 PEP의 범위에서 제외되었습니다. 필요하다면 향후 PEP에서 이 아이디어를 다시 검토할 수 있습니다.

현재 분류 시스템을 유지하되 옵션을 조정

이 PEP는 현재 시스템의 일부 사용성 문제를 해결하려 하면서도 PEP 438의 전반적인 취지를 유지하려는 몇 가지 관련 제안을 거부합니다.

여기에는 다음이 포함됩니다.

• 안전하게 외부에서 호스팅되는 파일은 기본적으로 허용하되, 안전하지 않게 호스팅되는 파일은 허용하지 않습니다.
• 기본적으로 안전하게 외부 호스팅된 파일은 이를 활성화하는 전역 플래그가 있을 때만 허용하고, 안전하지 않게 호스팅된 파일은 허용하지 않습니다.
• 제안된 PEP 438의 경로를 계속 따르되, 외부에서 안전하지 않게 호스팅하는 옵션은 제거하고, 외부에서 안전하게 호스팅하는 옵션은 계속 허용합니다.

이 제안들이 거부된 이유는 다음과 같습니다:

• 이 분류 체계는 PEP 438에서 도입되었으며, PyPI에 완전히 고유한 개념으로서 Python 패키징이라는 맥락에서도 일반적으로 적용될 수 없습니다. 개념을 추가로 도입하는 데는 비용이 따릅니다.
• 분류 체계 자체를 설명하기가 명확하지 않으며, 어떤 프로젝트가 어떤 링크 분류를 필요로 하는지 미리 판단하려면 해당 프로젝트의 /simple/<project>/ 페이지, 그리고 경우에 따라 그 페이지에서 링크된 모든 URL을 살펴봐야 합니다.
• 자동 검색을 위해 링크된 상태를 유지하면서 외부 호스팅하는 능력은 대체로 역사적 유물로, 얻는 보상에 비해 상당한 고통과 복잡성을 야기합니다.
• 암묵적으로 이루어져야 하는 링크 스크레이핑의 특성상, 설치 프로그램이 사용자 인터페이스를 최적화하거나 정리할 수 있는 능력은 제한됩니다. 이는 --allow-* 옵션뿐 아니라, 어떤 링크가 실패할 것으로 예상되는지 판단할 수 없다는 문제로도 이어집니다.
• 이 메커니즘은 옵션을 활성화할 때 매우 광범위하게 적용되는 반면, PEP 438은 패키지별 옵션으로 이를 제한하려 시도합니다. 그러나 오랜 기간 존재해 온 프로젝트는 종종 simple index에 여러 개의 서로 다른 URL이 나열되어 있는 경우가 많습니다. 그중 적어도 하나가 더 이상 해당 프로젝트의 통제 하에 있지 않은 경우가 드물지 않습니다. 등록되지 않은 도메인은 대부분의 경우 비교적 무해하게 방치되어 있지만, pip는 검색 단계마다 계속해서 그곳으로부터 설치를 시도합니다. 이는 공격자가 안전하지 않은 외부 URL에 의존하는 프로젝트들을 살펴보고 만료된 도메인을 등록하기만 하면 사용자를 공격할 수 있다는 것을 의미합니다.

이 PEP를 구현하되, 기존 링크는 제거하지 않기

이는 본질적으로 이 PEP의 하위 호환성 버전입니다. 이는 이전 클라이언트를 사용하는 사람들, 또는 이 PEP를 구현하지 않은 클라이언트를 사용하는 사람들이 마치 아무것도 변경되지 않은 것처럼 계속 이용할 수 있도록 하려는 시도입니다. 이 제안은 그러한 시나리오의 대부분이 사용이 중단 예정인 기능(deprecated features)의 안전하지 않은 사용에 해당한다는 이유로 거부됩니다. 최종 사용자를 대신하여 안전하지 않은 작업이 조용히 이루어지도록 허용하는 것은 결코 받아들일 수 있는 해결책이 아니라는 것이 이 PEP의 견해입니다.

Copyright

This document has been placed in the public domain.