[Withdrawn] PEP 759 - External Wheel Hosting

원문 링크: PEP 759 - External Wheel Hosting

상태: Withdrawn 유형: Standards Track 작성일: 01-Oct-2024

PEP 759 – External Wheel Hosting (외부 휠 호스팅)

작성자: Barry Warsaw, Emma Harper Smith PEP 위임자: Donald Stufft 논의: Discourse 스레드 상태: 철회됨 (Withdrawn) 유형: 표준 트랙 (Standards Track) 주제: 패키징 (Packaging) 생성일: 2024년 10월 1일 해결일: 2025년 1월 31일

초록 (Abstract)

이 PEP는 pypi.org에 호스팅된 프로젝트가 PyPI가 아닌 외부 사이트에 휠(wheel) 아티팩트를 안전하게 호스팅할 수 있는 메커니즘을 제안했습니다. 이 PEP는 프로젝트, 패키지 또는 해당 메타데이터의 외부 호스팅을 명시적으로 제안하지 않았습니다. 해당 기능은 독립적인 패키지 인덱스를 외부에서 호스팅함으로써 이미 사용할 수 있습니다. 이 PEP는 프로젝트가 특정 릴리스된 휠 아티팩트의 다운로드 URL을 사용자 정의할 수 있는 메커니즘만을 제공하므로, pip 및 uv와 같은 일반적인 설치 도구에 의해 이미 구현된 의존성 해결은 변경할 필요가 없습니다.

이 PEP는 이 맥락에서 “안전하다”는 것이 무엇을 의미하는지, 그리고 .rim 파일이라고 불리는 새로운 패키지 업로드 파일 형식을 정의합니다. 또한 .rim 파일이 HTML 및 JSON 형식 모두에서 패키지의 Simple Repository API에 대해 반환되는 메타데이터에 어떤 영향을 미치는지, 그리고 기존의 휠을 .rim 파일로 쉽게 변환하는 방법을 정의했습니다.

PEP 철회 (PEP withdrawn)

이 PEP는 2025년 1월 31일에 작성자들에 의해 철회되었습니다. 논의 스레드에서 나타난 의견에 따르면, 이 PEP가 해결하려던 문제들은 유효하지만, 대부분의 사람들은 다른 접근 방식을 선호했습니다. 특히, 대부분의 사용자들은 여러 인덱스를 지정하는 기능, 이러한 인덱스들이 어떻게 상호 운용되는지, 그리고 인덱스에 대한 우선순위 및 신뢰 주장(trust assertions)에 대해 더 많은 제어권을 선호하는 것으로 파악되었습니다. 예를 들어, PEP 766과 같은 해결책이 더 나은 방향을 제시할 수 있습니다. 현재의 임시방편(예: PyPI 제한 증가 요청 및 “휠 스텁” 접근 방식)은 이상적이지는 않지만, 그동안 충분하다고 판단되었습니다. 작성자들은 건설적인 논의에 기여해주신 모든 분들, 특히 공개적으로나 비공개적으로 이 PEP를 지지해주신 분들께 감사를 표했습니다.

근거 (Rationale)

PyPI 제한 문제 해결 (Addressing PyPI limits)

https://pypi.org에 호스팅된 Python Package Index는 업로드 아티팩트 파일 크기(100MiB) 및 총 프로젝트 크기(10GiB)에 기본 제한을 부과합니다. 대부분의 프로젝트는 수년간의 업로드를 통해 이러한 제한 내에서 편안하게 작업할 수 있습니다. 그러나 일부 프로젝트는 이러한 제한에 도달하여 파일 크기 및 프로젝트 크기 예외를 부여받았으며, 소비자가 여전히 사용하고 있을 수 있는 파일(예: 버전 고정을 통해)을 제거하는 것과 같은 더 과감한 조치를 취하지 않고도 새 릴리스를 계속 업로드할 수 있었습니다.

관련된 해결책으로 “휠 스텁(wheel stub)” 접근 방식이 있습니다. 이는 PyPI와 외부 서드파티 패키지 인덱스 간의 간접적인 링크를 제공하며, 이러한 제한을 피할 수 있습니다. 휠 스텁은 PEP 517 빌드 백엔드를 사용하는 소스 배포판(일명 “sdist”)으로, 소스 코드를 바이너리 휠로 변환하는 대신, 외부에서 호스팅되는 기존 휠을 다운로드하고 설치하기 위한 URL을 계산하는 로직을 수행합니다. 이 접근 방식은 작동하지만, PyPI, sdist, 그리고 외부 호스팅된 휠 간의 연결을 모호하게 만듭니다. 이는 pip 또는 다른 유사한 도구에 이 정보를 제시할 방법이 없기 때문입니다.

운영 복잡성 감소 (Reducing operational complexity)

전체 패키지 인덱스를 설정하고 유지하는 것은 시간과 리소스가 많이 소요되는 복잡한 운영 솔루션이 될 수 있습니다. 이는 특히 그러한 인덱스의 주요 목적이 단지 파일 크기 제한을 피하는 것일 때 더욱 그러합니다. 외부 인덱스 접근 방식은 또한 외부 인덱스의 프로젝트 소비자에게 까다로운 사용자 경험(UX)을 부과하여, --external-index-url과 같은 CLI 옵션이 어떻게 작동하는지, 그리고 그러한 플래그의 보안 영향을 이해하도록 요구합니다.

대용량 휠 패키지의 생산자와 소비자 모두에게는 HTTP GET보다 복잡한 API 없이 개별 파일을 제공할 수 있는 간단한 웹 서버를 설정하고 유지하는 것이 훨씬 쉬울 것입니다. 이러한 인터페이스는 캐싱하기 쉽거나 CDN 뒤에 배치하기 쉽습니다. 간단한 HTTP 서버는 보안 목적으로 감사하기 훨씬 쉽고, 프록시하기 쉬우며, 일반적으로 실행, 지원 및 유지 관리에 훨씬 적은 리소스가 필요합니다. 심지어 Amazon S3와 같은 서비스도 외부 휠을 호스팅하는 데 사용될 수 있습니다.

이 PEP는 이러한 운영상의 단순성을 선호하는 접근 방식을 제안했습니다.

다중 인덱스의 문제점 (The problem with multiple indexes)

PEP 470은 명시적인 여러 저장소(repository) 사용을 장려했습니다. 이는 pip install --extra-index-url과 같은 설치 도구 지원을 통해 pip이 여러 저장소를 패키지 설치 해결을 위한 단일 전역 저장소로 취급할 수 있도록 합니다. 이는 오랫동안 권장되는 표준이었으므로, 모든 Python 패키지 설치 도구는 의존성 해결을 위해 여러 인덱스를 쿼리하는 것을 지원합니다.

그러나 여러 인덱스를 통합할 때 발생하는 잘 알려진 문제 중 하나는 의존성 혼란 공격(dependency confusion attacks)입니다. Python은 pip install이 패키지 의존성과 선호 버전을 해결하는 데 사용하는 알고리즘 때문에 특히 취약할 수 있습니다. uv 도구는 추가 인덱스 전략 옵션을 지원하여 이러한 문제를 해결합니다. 이를 통해 사용자는 pip 호환 전략과 이러한 의존성 혼란 공격을 방지하는 더 제한적인 전략 중에서 선택할 수 있습니다.

PEP 708은 의존성 혼란 공격에 대한 추가 배경 정보를 제공하며, 이를 방지하기 위한 다른 접근 방식을 취합니다. PEP 708은 저장소 소유자가 프로젝트가 다른 저장소 간에 추적됨을 나타낼 수 있도록 하여, 설치 프로그램이 여러 저장소를 결합할 때 전역 패키지 네임스페이스를 처리하는 방법을 결정할 수 있도록 합니다. PEP 708은 잠정적으로 수락되었지만, PEP 708에 명시된 여러 필수 조건이 충족되어야 하며, 그중 일부는 불확실한 미래를 가질 수 있습니다. PEP 708 자체에서 언급했듯이, 이것만으로는 의존성 혼란 공격을 해결할 수 없지만, 설치 프로그램이 이러한 공격을 최소화하는 데 도움이 될 충분한 정보를 제공하는 한 가지 방법입니다.

사양 (Specification)

.rim (Remote Installable Metadata) 파일이라고 불리는 새로운 유형의 업로드 가능한 파일이 정의되었습니다. 이 이름은 타이어가 제거된 휠의 이미지를 연상시키며, .rim 파일이 .whl 파일에서 쉽게 파생될 수 있음을 강조합니다. .whl 파일을 .rim으로 변환하는 과정은 아래에 설명되어 있습니다. 파일 이름 형식은 휠 파일 이름 지정 사양과 정확히 일치하지만, .rim 파일은 .rim 접미사를 사용합니다. 이는 .whl 파일을 구별하는 데 사용되는 모든 태그가 다른 .rim 파일도 구별하며, 따라서 현재 .whl 파일과 마찬가지로 의존성 해결 단계에서 사용될 수 있음을 의미합니다. 이 점에서 .whl과 .rim 파일은 상호 교환이 가능합니다.

.rim 파일의 내용은 .whl 파일과 거의 동일하지만, .rim 파일은 휠에서 .dist-info 디렉토리만을 포함해야 합니다. .rim zip 파일에는 다른 최상위 파일이나 디렉토리가 허용되지 않습니다. .dist-info 디렉토리에는 .whl 파일의 .dist-info 디렉토리에서 허용되는 파일 외에 EXTERNAL-HOSTING.json이라는 단일 추가 파일이 포함되어야 합니다.

이 JSON 파일에는 다음 키가 포함됩니다.

  • version: 파일 형식 버전으로, 이 PEP에서는 1.0이어야 합니다.
  • owner: 이 외부 호스팅 파일의 PyPI 조직 소유자를 명시해야 합니다.
  • uri: 외부 사이트에 호스팅된 실제 .whl 파일의 위치를 나타내는 단일 URL입니다. 이 URL은 https 스키마를 사용해야 합니다.
  • size: 원격 호스트에 있는 실제 .whl 파일의 크기(바이트 단위)를 나타내는 정수 값입니다.
  • hashes: PEP 694에 설명된 형식의 딕셔너리로, 해당 PEP에서 제안된 것과 동일한 제약 조건으로 실제 .whl 파일의 해시를 캡처하는 데 사용됩니다. 이러한 해시는 PyPI에 업로드되면 변경할 수 없으므로, 외부 호스팅된 휠이 손상되거나 침해되지 않았다는 중요한 유효성 검사 역할을 합니다.

RIM 파일의 영향 (Effects of the RIM file)

.rim 파일의 유일한 영향은 단순 저장소 API의 HTML 및 JSON 인터페이스 모두에서 휠 아티팩트의 다운로드 URL을 변경하는 것입니다. 패키지 릴리스의 HTML 페이지에서 href 속성은 uri 키의 값이어야 하며, #<hashname>=<hashvalue> 프래그먼트를 포함해야 합니다. 이 해시 프래그먼트는 .dist-info/RECORD 파일에 있는 PEP 376에서 유래한 서명된 휠 파일 형식에 설명된 것과 정확히 동일한 형식이어야 합니다. 해시 알고리즘 및 인코딩 선택에 대한 정확히 동일한 규칙이 여기에서도 사용됩니다.

마찬가지로 JSON 응답에서 다운로드 파일을 가리키는 url 키는 uri 키의 값이어야 하며, hashes 딕셔너리는 위에 제공된 hashes 딕셔너리의 값으로 채워져 포함되어야 합니다.

다른 모든 면에서, 준수하는 패키지 인덱스는 아래에 설명된 몇 가지 사소한 예외를 제외하고는 .rim 파일을 .whl 파일과 동일하게 처리해야 합니다. 예를 들어, .rim 파일은 .whl 파일과 마찬가지로 동일한 의미(즉, 삭제는 영구적)로 삭제 및 인출(yanked, PEP 592)될 수 있습니다. .rim이 삭제되면 인덱스는 일치하는 .whl 또는 .rim 파일의 (재)업로드를 허용해서는 안 됩니다.

가용성 순서 (Availability order)

외부 호스팅된 휠은 해당 .rim 파일이 PyPI에 업로드되기 전에 사용할 수 있어야 합니다. 그렇지 않으면 게시 경합 조건(publishing race condition)이 발생할 수 있습니다. 단, PEP 694 스테이징 릴리스에 업로드되는 .rim 파일의 경우 이 요구 사항이 완화될 수 있습니다.

휠이 RIM을 재정의할 수 있음 (Wheels can override RIMs)

인덱스는 정확히 동일한 파일 이름 태그를 가진 일치하는 .whl 파일이 이미 존재하는 경우 .rim 파일을 거부해야 합니다. 그러나 인덱스는 일치하는 .rim 파일이 존재하는 경우 .whl 파일을 허용할 수 있습니다. 단, 해당 .rim 파일이 삭제되거나 인출되지 않았어야 합니다. 이는 업로더가 외부 호스팅된 휠 파일을 인덱스 호스팅된 휠 파일로 교체할 수 있도록 하지만, 그 반대는 금지됩니다. 기본적으로 휠은 패키지 메타데이터를 포함하는 동일한 패키지 인덱스에 호스팅되므로, 한 번 업로드된 기존 휠 파일을 “다운그레이드”하는 것은 허용되지 않습니다. .whl이 .rim을 대체할 때, 인덱스는 자체 호스팅 파일 서비스를 사용하여 패키지에 대한 다운로드 URL을 제공해야 합니다. 재정의하는 .whl 파일을 업로드할 때, 패키지 인덱스는 기존 .rim 파일의 해시를 검증해야 하며, 이러한 해시가 일치하지 않으면 재정의 업로드는 거부되어야 합니다.

PyPI API 버전 업 불필요 (PyPI API bump unnecessary)

변경 사항은 PyPI 저장소 버전의 변경이 필요 없을 정도로 이전 버전과 충분히 호환될 가능성이 높습니다. .rim 파일은 기본적으로 업로드 API에 대한 변경 사항일 뿐이므로, 패키지 리졸버 및 패키지 설치 프로그램은 항상 지원해온 API로 계속 기능할 수 있습니다.

외부 호스팅 탄력성 (External hosting resiliency)

PEP 438이 PEP 470에서 취소된 주요 우려 사항 중 하나는 외부 인덱스가 사라질 때 발생할 수 있는 사용자 혼란이었습니다. PEP 470에 따르면:

이러한 혼란은 프로젝트의 최종 사용자가 프로젝트가 PyPI에 호스팅되어 있는지 또는 외부 서비스에 의존하는지 인지하지 못하는 데서 비롯됩니다. 이는 종종 외부 서비스가 다운되었지만 PyPI는 그렇지 않은 경우에 발생합니다. 사람들은 PyPI가 작동하고 다른 프로젝트는 작동하지만 이 특정 프로젝트는 작동하지 않는 것을 보게 됩니다. 그들은 종종 이것을 해결하기 위해 누구에게 연락해야 하는지 또는 어떤 조치 단계를 취해야 하는지 깨닫지 못합니다.

외부 휠 호스팅 서비스가 다운되는 문제는 이 PEP에서 직접 해결되지는 않지만, PyPI 관리자에게 잠재적인 부담을 크게 줄이기 위한 여러 보호 장치가 마련되어 있습니다.

따라서 이 PEP는 다음을 제안합니다.

  • 외부 휠 호스팅은 조직 계정이 소유한 패키지에만 허용됩니다.
  • 외부 호스팅은 조직 전체 설정입니다.
  • 조직 계정은 외부 휠을 호스팅할 수 있는 기능을 자동으로 얻지 못합니다. 이 기능은 PyPI 관리자의 재량에 따라 명시적으로 활성화되어야 합니다.
  • 이러한 요청은 흔하지 않을 것이므로, PEP 541 해결, 계정 복구 요청 또는 파일/프로젝트 크기 증가 요청만큼 부담이 크지 않을 것으로 예상됩니다. 외부 호스팅 요청은 이러한 요청과 동일한 방식으로, 즉 PyPI GitHub 지원 트래커를 통해 처리됩니다.
  • 외부 휠 호스팅을 요청하는 조직 계정은 메일 주소의 mailto URI이든 조직의 지원 트래커 URL이든 자체 지원 연락처 URI를 등록해야 합니다. 외부 휠 파일 호스팅을 이용하지 않는 조직의 경우 이러한 연락처 URI는 선택 사항입니다.

EXTERNAL-HOSTING.json 파일의 owner 키와 결합하여, 이는 설치 도구가 다운로드 오류를 PyPI 지원 관리자로부터 명확하게 조직의 지원 관리자에게 리디렉션할 수 있도록 합니다.

이 조직 지원 URL을 저장하고 검색하는 정확한 메커니즘은 별도로 정의되겠지만, 예를 들어 foo라는 패키지가 https://foo.example.com에 휠 파일을 외부 호스팅하고 해당 호스트에 연결할 수 없게 되면 어떻게 되는지 살펴봅니다. 설치 도구가 foo 패키지 휠을 다운로드하고 설치하려고 시도하면 다운로드 단계가 실패합니다. 그러면 설치 프로그램은 PyPI를 쿼리하여 최종 사용자에게 유용한 오류 메시지를 제공할 수 있습니다.

설치 프로그램은 .rim 파일을 다운로드하고 .rim zip 파일 내의 EXTERNAL-HOSTING.json 파일에서 owner 키를 읽습니다. 설치 프로그램은 외부 호스팅된 휠의 조직 소유자에 대한 지원 URI를 PyPI에 쿼리합니다. 그러면 다음과 같은 정보성 오류 메시지가 표시됩니다.

The externally hosted wheel file foo-….whl could not be downloaded. Please contact support@foo.example.com for help. Do not report this to the PyPI administrators. (외부 호스팅된 휠 파일 foo-….whl을 다운로드할 수 없습니다. 도움을 받으려면 support@foo.example.com으로 연락하십시오. PyPI 관리자에게 보고하지 마십시오.)

휠 분리 (Dismounting wheels)

기존 .whl 파일에서 .rim 파일을 생성하는 것은 일반적으로 매우 쉽습니다. 이는 추가 명령줄 옵션이 있는 PEP 518 빌드 백엔드 또는 .whl 파일을 입력으로 받아 관련 .rim 파일을 생성하는 별도의 도구에 의해 효율적으로 수행될 수 있습니다. 비유를 완성하기 위해 .whl을 .rim으로 변환하는 행위를 “분리(dismounting)”라고 부릅니다. 그러한 도구가 취할 단계는 다음과 같습니다.

  • 입력으로 원본 .whl 파일, 패키지의 조직 소유자, .whl이 호스팅될 URL, 다운로드 문제 보고를 위한 지원 URI를 받습니다. 이러한 정보는 pyproject.toml 파일에 캡처될 수도 있지만, 해당 사양은 이 PEP의 범위를 벗어납니다.
  • .whl의 압축을 풀고 .rim zip 아카이브를 생성합니다.
  • .dist-info 디렉토리에 없는 .whl의 모든 경로를 .rim 파일에서 생략합니다.
  • 원본 .whl 파일의 해시를 계산합니다.
  • 위에 설명된 JSON 키와 값을 포함하는 EXTERNAL-HOSTING.json 파일을 .rim 아카이브에 추가합니다.

도구 변경 사항 (Changes to tools)

이론적으로 설치 도구는 어떤 변경도 필요하지 않습니다. 다운로드하고 설치할 휠을 식별하면 PyPI의 Simple API에서 반환된 다운로드 URL을 단순히 참조하기 때문입니다. 그러나 실제로는 pip 및 uv와 같은 도구는 PyPI의 자체 pythonhosted.org 도메인과 같이 다운로드를 허용하는 호스트 목록이 제한적일 수 있습니다.

이 경우 이러한 도구는 해당 제약을 완화해야 하지만, 이에 대한 정확한 정책은 설치 도구 자체에 맡겨져 있습니다. .rim 파일을 다운로드하고 EXTERNAL-HOSTING.json 메타데이터를 확인하거나, 일치하는 체크섬이 있는 모든 휠에 대해 외부 다운로드를 단순히 신뢰하는 등 여러 접근 방식이 구현될 수 있습니다. 또한 다운로드를 신뢰하기 전에 프로젝트의 조직 소유자 및 지원 URI에 대해 PyPI를 쿼리할 수 있습니다. 외부 호스팅된 휠 파일이 발견될 때 사용자에게 경고하거나, 추가 다운로드 호스트를 활성화하기 위해 명령줄 옵션 사용을 요구할 수 있습니다. 이러한 검증 정책은 구성 파일에서 선택할 수 있습니다.

설치 도구는 또한 외부 호스팅된 휠을 다운로드할 수 없는 경우(예: 호스트에 연결할 수 없는 경우) 더 나은 오류 메시지를 제공해야 합니다. 위에 설명된 대로 이러한 도구는 PyPI에서 충분한 메타데이터를 쿼리하여 사용자에게 패키지의 외부 호스팅 지원 이메일 또는 문제 추적기를 안내하는 명확하고 구별되는 오류 메시지를 제공할 수 있습니다.

외부 호스팅 서비스에 대한 제약 조건 (Constraints for external hosting services)

다음 제약 조건은 안정적이고 호환 가능한 외부 휠 호스팅 서비스로 이어집니다.

  • 외부 휠은 Mozilla의 루트 인증서 저장소에서 서명한 인증서를 사용하여 HTTPS를 통해 제공되어야 합니다. 이는 pip 및 uv와의 호환성을 보장합니다.
  • 외부 휠 호스트는 PyPI와 마찬가지로 CDN(콘텐츠 전송 네트워크)을 사용해야 합니다.
  • 외부 휠 호스트는 호스팅하는 모든 휠에 대해 안정적인 URL을 약속해야 합니다.
  • 외부 호스팅된 휠은 해당 .rim 파일이 PyPI에서 먼저 삭제되지 않는 한 외부 휠 호스트에서 제거되어서는 안 되며, 인출된 릴리스에 대한 외부 휠을 제거해서는 안 됩니다.
  • 외부 휠 호스트는 HTTP 범위 요청(range requests)을 지원해야 합니다.
  • 외부 휠 호스트는 HTTP/2 프로토콜을 지원해야 합니다.

보안 (Security)

이 제안에 설명된 여러 요소는 외부 호스팅된 휠의 보안 우려를 완화해야 합니다.

  • 휠 파일 체크섬은 .rim 파일에 포함되어야 하며, 일단 업로드되면 변경할 수 없습니다. PyPI에 저장된 체크섬은 변경 불가능하고 필수적이므로, 소유 조직이 호스팅 도메인에 대한 제어권을 잃더라도 외부 휠 파일을 스푸핑하는 것은 불가능합니다.
  • 외부 호스팅된 휠은 HTTPS를 통해 제공되어야 합니다.
  • 외부 호스팅된 휠을 제공하려면 조직은 PyPI 관리자의 승인을 받아야 합니다.

사용자가 PyPI 호스팅 프로젝트에서 맬웨어 또는 취약점을 식별하면, 이제 PyPI의 맬웨어 보고 기능을 사용하여 이를 보고할 수 있습니다. 동일한 프로세스를 사용하여 외부 호스팅된 휠의 보안 문제를 보고할 수 있으며, 동일한 해결 프로세스가 사용되어야 합니다. 또한, 외부 호스팅이 활성화된 조직은 지원 연락처 URI를 제공해야 하므로, 해당 URI는 경우에 따라 호스팅 조직에 보안 문제를 보고하는 데 사용될 수 있습니다. 이러한 조직 보고는 맬웨어에는 적합하지 않지만, 외부 호스팅된 휠의 보안 취약점을 보고하는 데 매우 유용할 수 있습니다.

거부된 아이디어 (Rejected ideas)

몇 가지 아이디어가 고려되었지만 거부되었습니다.

  • 외부 호스팅된 휠 파일에 대한 디지털 서명 요구: 체크섬 요구 사항만으로도 휠에 대한 PyPI의 메타데이터가 다운로드된 휠과 정확히 일치함을 검증하기에 충분하다고 판단되었습니다. 키 관리의 추가적인 복잡성은 디지털 서명이 제공할 수 있는 추가적인 이점보다 큽니다.
  • .rim 파일 업로드 시 해시 검증: PyPI는 업로드를 수락하기 전에 업로드된 .rim 파일의 해시가 외부 호스팅된 휠과 일치하는지 확인할 수 있지만, 이는 외부 휠을 다운로드하고 체크섬을 수행해야 하므로 외부 .whl 파일이 다운로드되고 검증될 때까지 .rim 파일의 업로드를 수락할 수 없음을 의미합니다. 이는 PyPI 대역폭을 증가시키고 업로드 쿼리를 느리게 만들지만, PEP 694 초안 업로드가 이러한 우려를 완화할 수 있습니다. 그럼에도 불구하고, 그 이점은 추가적인 복잡성만큼 가치가 없을 가능성이 높습니다.
  • 인덱스에 의한 다운로드 URL의 주기적 검증: PyPI는 HTTP HEAD 요청 등을 통해 외부 휠 호스트 또는 외부 .whl 파일 자체가 여전히 사용 가능한지 주기적으로 확인할 수 있습니다. 이는 과도할 가능성이 높으며, 응답에 파일의 체크섬을 제공하지 않는 한 많은 추가적인 이점을 제공하지 않을 수 있습니다.
  • 대체 다운로드 호스트 허용: 이 PEP는 조직이 대체 다운로드 호스트를 제공하여 주 호스트가 다운될 경우 보조 호스트를 사용할 수 있도록 허용할 수 있었습니다. 그러나 DNS 기반 복제가 훨씬 더 좋고 잘 알려진 기술이며, 아마도 훨씬 더 탄력적이라고 판단되었습니다.
  • .rim 파일 교체: .whl 파일이 기존 .rim 파일을 대체하는 것은 허용되지만(단, .rim 파일이 삭제되거나 인출되지 않았고, 체크섬이 일치하는 경우), .whl 파일을 .rim 파일로 대체하거나, .rim 파일이 기존 .rim 파일을 덮어쓰는 것은 허용되지 않습니다. 후자는 외부 호스팅된 .whl의 호스팅 URL을 변경하는 기술이 될 수 있지만, 이는 좋은 생각이 아니라고 판단되었습니다. 위에 설명된 대로 외부 호스트 URL을 “수정”하는 다른 방법이 있으며, 기존 .rim 파일의 대량 재업로드를 장려하고 싶지 않았습니다.

⚠️ 알림: 이 문서는 AI를 활용하여 번역되었으며, 기술적 정확성을 보장하지 않습니다. 정확한 내용은 반드시 원문을 확인하시기 바랍니다.

Comments