PEP 777 – 휠을 다시 발명하는 방법

Author:

Emma Harper Smith <emma at python.org>

Sponsor:

Barry Warsaw <barry at python.org>

PEP-Delegate:

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

Discussions-To:

Discourse thread

Status:

Draft

Type:

Standards Track

Topic:

Packaging

Created:

09-Oct-2024

Post-History:

10-Oct-2024

---

Table of Contents

• 초록
• 근거
• 사양
  • 핵심 메타데이터에 Wheel-Version 메타데이터 필드 추가
  • Wheel-Version에 관한 리졸버 동작
  • 첫 번째 주 버전 증가는 파일 확장자를 변경해야 합니다.
  • 새로운 휠 형식에서 권장되는 빌드 백엔드 동작
  • 향후 휠 개정의 제한 사항
• 하위 호환성
• 거부된 아이디어
  • 휠 형식은 완벽하며 변경할 필요가 없습니다
  • 휠 형식 변경은 CPython 릴리스에 연계되어야 합니다
  • 파일 확장자로 .whl 계속 사용하기
  • 파일 확장자에 휠 주 버전 저장하기(.whl2)
  • 휠 2.0에서는 외부 컨테이너 형식을 변경해야 합니다
  • 이 PEP에서 휠 2.0을 명세하지 않는 이유는 무엇입니까?
• 논의 주제
  • 최초 마이그레이션을 위해 색인에서 이중 게시를 지원해야 합니까?
• 감사의 말
• Copyright

번역·라이선스 안내

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

초록

현재의 휠 1.0 사양은 10여 년 전에 작성되었으며, Python 패키징 생태계의 변화에 매우 견고하게 대응해 왔습니다. 휠 사양을 개선하려던 이전의 노력은 다른 패키징 사양에 집중하기 위해 연기되었습니다. 한편, 지난 10년 동안 휠의 사용 방식은 극적으로 변했습니다. 수년 동안 새로운 휠 기능에 대한 요청이 많았지만, 휠 사양을 발전시키는 데 근본적인 장애물은 휠에 하위 호환성이 없는 기능을 추가할 때 이를 처리하는 정의된 절차가 없다는 점이었습니다. 따라서 다른 PEP가 휠 사양에 대한 새로운 개선 사항을 기술할 수 있도록, 이 PEP는 향후 휠 개정판에 대한 호환성 요구 사항을 규정합니다. 이 PEP는 새로운 휠 개정판을 지정하지 않습니다. 새로운 휠 형식(“Wheel 2.0”)의 사양은 향후 PEP에 맡깁니다.

근거

현재 새로운 설치 프로그램 동작이 필요한 휠 사양 변경은 하위 호환성이 없으며 휠 메타데이터 형식의 주 버전 증가가 필요합니다. 휠 주 버전의 증가는 아직 이루어지지 않았는데, 이는 부분적으로 그러한 변경이 치명적인 혼란을 일으킬 가능성이 있기 때문입니다. 휠 사양에 따르면, 새로운 주 버전을 지원하지 않는 모든 설치 프로그램은 설치 시 중단해야 합니다. 이는 추가 계획 없이 주 버전을 증가시키면, 공개 패키지 색인인 Python Package Index(PyPI)에 업로드된 새 휠을 이전 설치 프로그램이 거부함에 따라 많은 사용자가 설치 실패를 겪게 된다는 의미입니다. 호환성 문제를 피하려면 빌드 도구, 패키지 색인 및 패키지 설치 프로그램 간의 상호 작용을 신중하게 계획하는 것이 매우 중요하며, 특히 설치 프로그램 업데이트가 느린 사용자층이 장기간 남아 있다는 점을 고려해야 합니다.

하위 호환성에 대한 우려로 인해 휠 파일 형식의 가치 있는 개선 사항인 더 나은 압축, 휠 데이터 형식 개선, 휠에 포함된 항목에 대한 더 나은 정보 및 “.dist-info” 폴더의 JSON 형식 메타데이터가 실현되지 못했습니다.

이 PEP는 휠 형식의 새로운 주 버전을 지원하지 않는 기존 도구의 안정성을 유지하기 위해 새로운 휠 개정판에 대한 제약 조건과 동작을 설명합니다. 이를 통해 휠 사양의 하위 호환성이 없는 변경은 최신 휠을 사용하도록 올바르게 설정된 사용자와 도구에만 영향을 미치게 됩니다. 휠 사양을 발전시킬 명확한 경로가 있으면, 향후 PEP는 완전히 새로운 호환성 방식을 다시 정의하지 않고도 휠 형식을 개선할 수 있습니다.

사양

핵심 메타데이터에 Wheel-Version 메타데이터 필드 추가

현재 휠 1.0 PEP인 PEP 427은 휠 파일에 해당 파일이 준수하는 휠 사양의 버전을 포함하는 WHEEL 메타데이터 파일이 들어 있어야 한다고 규정합니다. PEP 427은 설치 프로그램이 지원되는 것보다 높은 부 버전의 휠을 설치할 때 경고해야 하며, 설치 프로그램이 지원하는 것보다 높은 주 버전의 휠을 설치할 때는 중단해야 한다고 규정합니다. 이를 통해 사용자는 설치 프로그램이 제대로 설치할 수 없는 휠로 인해 잘못된 설치를 받지 않게 됩니다.

그러나 현재 리졸버는 호환되지 않는 휠 버전의 휠을 제외하지 않습니다. 또한 현재 리졸버가 휠을 직접 다운로드하지 않고 휠의 버전을 확인할 방법도 없습니다. 리졸버가 휠 버전을 쉽게 필터링할 수 있도록, 휠 버전은 관련 메타데이터 파일(현재는 METADATA임)에 반드시 포함되어야 합니다. 이를 통해 리졸버는 .dist-info/WHEEL 파일을 다운로드하여 검사하지 않고도 PEP 658 메타데이터 API를 사용해 휠 버전을 효율적으로 확인할 수 있습니다.

이를 위해 새로운 필드인 Wheel-Version이 핵심 메타데이터 사양에 추가됩니다. 이 필드는 한 번만 사용되며, WHEEL 파일의 Wheel-Version 항목 또는 휠 파일에 대한 메타데이터를 정의하는 향후 대체 파일에 지정된 버전과 정확히 동일한 버전을 포함해야 합니다. 메타데이터 파일에 Wheel-Version이 없으면, 도구는 휠 파일의 메이저 버전을 1로 추론해야 합니다.

Wheel-Version은 소스 배포 메타데이터(PKG-INFO) 파일에 포함되어서는 안 됩니다. 도구가 소스 배포 메타데이터 파일 내에서 Wheel-Version을 발견하면, 오류를 발생시켜야 합니다.

버전 1 휠의 메타데이터 파일에는 Wheel-Version을 포함할 수 있지만, 버전 2 이상인 휠의 메타데이터 파일에는 Wheel-Version이 반드시 포함되어야 합니다. 이를 통해 휠 사양의 향후 개정판은 Wheel-Version 필드를 확인하여 리졸버가 호환되지 않는 휠을 건너뛸 것이라고 신뢰할 수 있습니다. 빌드 백엔드는 버전과 관계없이 생성하는 모든 휠에 Wheel-Version을 포함하는 것이 권장됩니다.

설치 관리자는 설치 중에 휠의 메타데이터 파일을 수정하지 않고 복사해야 합니다. 이렇게 하면 오류가 발생하기 쉬운 과정인 RECORD 파일 업데이트가 필요하지 않습니다. 설치된 코어 메타데이터를 읽는 도구는 다른 설치 형식에서 해당 필드를 생략할 수 있으므로, 필드가 존재한다고 가정해서는 안 됩니다.

휠을 설치할 때 설치 관리자는 다음 단계를 수행해야 합니다:

1. 핵심 메타데이터 파일과 휠 메타데이터 파일에 있는 Wheel-Version의 값이 일치하는지 확인합니다. 일치하지 않으면 설치 관리자는 설치를 중단해야 합니다. 어느 값도 우선하지 않습니다.
2. 설치 프로그램이 Wheel-Version과 호환되는지 확인합니다. Wheel-Version이 없으면 버전이 1.0이라고 가정합니다. 부 버전이 더 높으면 경고하고, 주 버전이 더 높으면 중단합니다. 이 절차는 PEP 427에 정의된 절차와 동일합니다.
3. Binary Distribution Format 사양에 지정된 대로 설치를 진행합니다.

Wheel-Version에 관한 리졸버 동작

리졸버는 설치할 휠을 선택하는 과정에서 후보 휠의 Wheel-Version을 확인해야 하며, 호환되지 않는 휠 파일은 무시해야 합니다. 이러한 파일을 무시하지 않으면 이전 버전의 설치 프로그램이 해당 설치 프로그램에서 지원하지 않는 휠 버전을 사용하는 휠을 선택할 수 있으며, 이에 따라 PEP 427에 따라 설치 프로그램이 중단될 수 있습니다. 호환되지 않는 휠 파일을 건너뛰면 프로젝트가 새로운 휠 주 버전을 채택할 때 사용자는 설치 오류를 보지 않게 됩니다. PEP 427에서 이미 지정된 대로, 사용자가 호환되지 않는 휠을 직접 설치하려고 하면 설치 관리자는 중단해야 합니다. 리졸버가 여러 색인에서 발견된 패키지를 해결하는 과정에서 동일한 배포 패키지와 버전을 가진 두 휠을 발견하면, 리졸버는 호환 가능한 버전 중 가장 높은 버전의 휠을 우선해야 합니다.

위의 동작은 예기치 않은 손상으로부터 사용자를 보호하지만, 설치 프로그램이 해당 릴리스에서 사용된 휠 버전을 지원하지 않으면 사용자가 배포 패키지의 새 릴리스를 놓칠 수 있습니다. 앞으로 어떤 패키지가 3.0 휠 파일을 배포한다고 가정해 보십시오. 사용자의 설치 프로그램이 2.x 휠만 지원한다면, 다운스트림 사용자는 새 릴리스가 제공된다는 사실을 알 수 없습니다. 따라서 설치 관리자는 패키지를 확인하는 과정에서 호환되지 않는 휠을 발견하여 건너뛰는 경우 경고를 표시해야 합니다.

첫 번째 주 버전 증가는 파일 확장자를 변경해야 합니다.

안타깝게도 기존 리졸버는 설치 후보로 선택하기 전에 휠의 호환성을 확인하지 않습니다. 대다수 사용자가 휠 호환성을 올바르게 확인하는 설치 프로그램으로 업데이트할 때까지는, 기존 리졸버가 선택할 수 있는 새로운 메이저 버전의 휠을 게시하도록 허용하는 것이 안전하지 않습니다. 현재 PyPI 설치 프로그램 사용량 데이터를 기준으로 보면 대다수 사용자가 업데이트된 리졸버를 사용하게 되기까지 4년 이상 걸릴 수 있습니다(자세한 내용은 부록: PyPI의 설치 프로그램 사용 분석를 참조하십시오). 2.0 휠을 실험하고 더 빠르게 도입할 수 있도록, 이 PEP에서는 향후 모든 휠 버전에 대해 휠 파일 형식의 파일 확장자를 .whl에서 .whlx로 변경할 것을 제안합니다. whlx의 x는 문자 “x”이며 휠 메이저 버전을 지정하지 않는다는 점에 유의하십시오. 확장자 이름을 변경하면 Wheel-Version확인을 구현하지 않는 기존 설치 프로그램에서 2.0 휠로 인해 사용자가 문제를 겪는 초기 전환 문제가 해결됩니다. 다른 파일 확장자를 사용하면 2.0 휠을 즉시 PyPI에 업로드할 수 있으며, 사용자는 새로운 기능을 바로 실험할 수 있습니다. 이전 설치 프로그램을 사용하는 사용자는 이러한 새 파일을 단순히 무시합니다.

한 가지 기각된 대안은 .whl 확장자를 유지하되 휠 2.0의 PyPI 게시를 지연하는 것입니다. 이에 대한 자세한 내용은 「기각된 아이디어」를 참조하십시오.

새로운 휠 형식에서 권장되는 빌드 백엔드 동작

빌드 백엔드는 프로젝트가 사용하는 기능을 바탕으로 가장 호환성이 높은 휠을 생성하는 것이 좋습니다. 예를 들어 휠이 심볼릭 링크를 사용하지 않고 그러한 기능이 휠 5.0에서 도입되었다면, 빌드 백엔드는 버전 4.0의 휠을 생성할 수 있습니다. 반면 일부 기능은 기본적으로 도입하는 것이 바람직할 수 있습니다. 예를 들어 휠 3.0에서 더 나은 압축을 도입한다면, 빌드 백엔드는 휠 크기와 다운로드 성능을 개선하기 위해 이 기능을 기본적으로 활성화할 수 있습니다.

향후 휠 개정의 제한 사항

휠 형식에 어떤 미래 기능이 계획되어 있을지 알기 어렵지만, 특정 호환성 약속을 유지하는 것이 중요합니다.

설치된 휠 파일은 지원되는 모든 CPython 버전에서 Python 표준 라이브러리의 importlib.metadata와 호환성을 MUST유지해야 합니다. 예를 들어, .dist-info/METADATA를 JSON 형식의 메타데이터 파일로 교체하는 것은 다중 메이저 버전 마이그레이션이어야 합니다. 한 버전에서 기존 이메일 헤더 형식과 함께 새로운 JSON 파일을 도입하고, 이후의 다른 버전에서 이메일 헤더 형식의 메타데이터 파일을 제거해야 합니다. .dist-info/METADATA를 제거하는 버전 역시 새 파일을 지원하지 않았던 마지막 CPython 릴리스가 수명 종료에 도달한 후에만 MUST채택해야 합니다. 이렇게 하면 importlib.metadata를 사용하는 코드가 휠 메이저 버전 개정으로 인해 중단되지 않습니다.

휠 파일은 외부 컨테이너 형식으로서 MUSTZIP 형식 파일로 유지되어야 합니다. 또한 .dist-info메타데이터 디렉터리는 어떤 압축도 적용하지 않고 아카이브의 루트에 MUST배치해야 하며, 이렇게 해야 휠 파일의 압축을 풀었을 때 휠의 모든 메타데이터를 담은 일반적인 .dist-info디렉터리가 생성됩니다. 향후 휠 개정에서는 데이터와 코드 같은 휠의 비메타데이터 구성 요소에 대해 레이아웃, 압축 및 기타 속성을 MAY수정할 수 있습니다. 이를 통해 향후 휠 개정은 패키지 메타데이터를 처리하는 도구와의 호환성을 유지하면서, 압축 도입과 같은 휠 내 코드 저장 방식의 개선도 가능하게 됩니다.

패키지 도구는 위에서 설명한 메타데이터 폴더 내용 및 외부 컨테이너 형식에 관한 제한을 제외하고, 향후 휠 메이저 버전에서도 휠 파일의 내용과 형식이 동일하게 유지될 것이라고 MUST NOT가정해서는 안 됩니다. 예를 들어 최신 휠 메이저 버전에서는 빌드 태그나 플랫폼 태그와 같은 파일 이름 구성 요소를 추가하거나 제거할 수 있습니다. 따라서 도구는 휠 설치를 시도하기 전에 Wheel-Version메타데이터를 확인해야 합니다.

마지막으로 향후 휠 개정에서는 최소한 최신 릴리스의 CPython 표준 라이브러리에 포함되지 않은 압축 형식을 MUST NOT사용해야 합니다. 새로운 압축 형식을 사용하여 생성된 휠에는 휠 내부 코드의 Python API 호환성과 관계없이, 새로운 압축 형식을 지원하는 CPython의 최초 릴리스 버전 이상이 필요하다는 태그를 지정해야 합니다.

하위 호환성

하위 호환성은 휠 형식을 발전시키는 데 있어 매우 중요한 문제입니다. 새로운 휠 리비전을 도입하는 일이 다운스트림 사용자에게 고통스럽다면, 패키지 작성자는 새로운 표준 도입을 주저하게 되고, 사용자는 실패한 CI 파이프라인과 그 밖의 설치 문제에 발이 묶이게 됩니다.

위 사양의 몇 가지 선택은 새로운 기능의 도입이 덜 고통스럽도록 이루어졌습니다. 예를 들어, 현재 호환되지 않는 메이저 버전의 휠도 pip가 여전히 설치 후보로 선택하며, 이로 인해 프로젝트가 2.0 휠을 게시하기 시작하면 설치 프로그램이 실패합니다. 이 문제를 피하기 위해 이 PEP는 리졸버가 설치 프로그램과 호환되지 않는 메이저 버전이나 기능을 포함한 휠을 걸러 내도록 요구합니다.

이 PEP는 또한 CPython과의 호환성을 유지하면서 휠 콘텐츠가 발전할 수 있도록 향후 휠 리비전에 대한 제약 조건을 정의합니다. 휠 리비전으로 인해 이전 CPython 리비전에서 패키지 설치가 중단되어서는 안 됩니다. 사용자에게 좌절감을 줄 뿐만 아니라 디버깅이 매우 어렵기 때문입니다.

이 PEP는 리졸버가 일반적으로 PEP 658을 통해 패키지 메타데이터를 효율적으로 가져올 수 있다는 전제에 의존합니다. 이는 PEP 658 메타데이터를 제공하지 않는 패키지 색인의 사용자에게 문제가 될 수 있습니다. 그러나 현재 대부분의 설치 프로그램은 HTTP 범위 요청을 사용하여 메타데이터를 읽는 데 필요한 휠의 부분만 효율적으로 가져오는 방식으로 대체하며, 이 기능은 대부분의 스토리지 제공업체와 서버에 포함되어 있습니다. 또한 압축과 같은 향후 휠 개선을 통해 휠 내부의 파일을 검사하는 데 따른 성능 손실을 보충할 수 있습니다.

이 PEP의 주요 호환성 제한은 소스 배포본과 함께 새로운 휠만 게시하기 시작하는 프로젝트에 적용됩니다. 이전 설치 프로그램을 사용하는 사용자가 패키지를 설치하려고 하면, 리졸버가 모든 최신 휠을 건너뛰기 때문에 소스 배포본으로 대체됩니다. 사용자는 소스에서 프로젝트를 빌드할 준비가 제대로 되어 있지 않은 경우가 많으므로, 이로 인해 그렇지 않았다면 사용자가 겪지 않았을 일부 빌드 실패가 발생할 수 있습니다. 이 문제를 해결하는 방법에는 초기 마이그레이션을 위해 이중 게시를 허용하거나, 소스 배포본을 빌드할 의도가 없다고 표시하는 것 등이 있습니다.

거부된 아이디어

휠 형식은 완벽하며 변경할 필요가 없습니다

휠 형식은 10년 넘게 사용되어 왔으며, 그동안 Python 패키지는 크게 변화했습니다. 패키지에 Rust 또는 C 확장 모듈을 포함하는 일이 훨씬 일반화되어 패키지의 크기가 증가하고 있습니다. lzma 또는 zstd와 같은 더 나은 압축을 사용하면 PyPI와 그 사용자에게 많은 시간과 대역폭을 절약할 수 있습니다. 호환성 태그는 오늘날 Python 코드를 가속하는 데 사용되는 매우 다양한 하드웨어를 표현할 수 없으며, 공유 라이브러리 호환성 정보도 인코딩할 수 없습니다. 이러한 문제를 해결하려면 휠 패키지 형식을 발전시켜야 합니다.

휠 형식 변경은 CPython 릴리스에 연계되어야 합니다

휠 리비전을 CPython 릴리스에 연계하는 것이 유익하다고 생각하지 않습니다. 그렇게 하는 주된 이점은 새로운 휠의 도입을 예측 가능하게 만드는 것입니다. 최신 CPython을 사용하는 사용자는 최신 패키지 형식을 얻게 됩니다! 그러나 이 선택에는 몇 가지 문제가 있습니다. 첫째, 새로운 형식을 최신 CPython에 연계하면 도입 속도가 훨씬 느려집니다. 이전 Python 설치를 사용하는 Linux LTS 버전의 사용자는 가상 환경에서 pip를 자유롭게 업데이트할 수 있지만, Python 버전은 쉽게 업데이트할 수 없습니다. 새로운 압축 형식 추가나 메타데이터 형식 변경처럼 휠 형식의 일부 변경은 반드시 CPython 변경 사항에 연계되어야 하지만, 심볼릭 링크, 향상된 호환성 태그, 표준 라이브러리의 기존 압축 형식을 사용하는 새로운 형식처럼 Python 버전에 연계할 필요가 없는 변경도 많습니다. 또한 휠은 여러 서로 다른 언어 구현에서 사용되며, 이러한 구현은 CPython 버전에 뒤처집니다. Python 버전 때문에 해당 사용자가 기능을 사용하지 못하도록 하는 것은 공정하지 않은 것처럼 보입니다. 마지막으로, 이 PEP는 휠 버전을 CPython 릴리스에 연계하자고 제안하지 않지만, 향후 PEP에서 언제든 그렇게 할 수 있으므로 이 PEP에서 이 선택을 결정할 필요는 없습니다.

파일 확장자로 .whl 계속 사용하기

확장자 .whl을 유지하는 것은 여러 이유로 매력적이지만, 극복하기 어려운 몇 가지 문제를 제시합니다. 우선 현재 설치 프로그램은 여전히 새 휠을 선택하고 패키지 설치에 실패합니다. 또한 정해진 휠 파일 이름 형식을 예상하는 기존 설치 프로그램을 중단시키지 않고는 휠의 파일 이름을 변경할 수 없습니다. 현재 휠의 파일 이름 명세는 현재 사용에 충분하지만, 파일 이름 중간의 선택적 빌드 태그로 인해 모든 확장 방식이 모호해집니다(즉, foo-0.3-py3-none-any-fancy_new_tag.whl은 빌드 태그가 py3인 것으로 분석됩니다). 이로 인해 휠 파일 이름에 저장되는 정보의 변경이 제한됩니다.

파일 확장자에 휠 주 버전 저장하기(.whl2)

파일 확장자에 휠 주 버전을 저장하면 몇 가지 유용한 장점이 있습니다. 우선 설치 프로그램이 파일 확장자에 따라 간단히 필터링할 수 있으므로 Wheel-Version 메타데이터 필드를 도입할 필요가 없습니다. 또한 이를 통해 향후 나란히 설치되는 패키지를 허용할 수 있습니다. 그러나 각 주 버전마다 휠의 확장자를 변경하면 몇 가지 단점이 있습니다. 우선 WHEEL 파일에 저장된 버전이 파일 확장자와 일치해야 하며, 이를 설치 프로그램이 검증해야 합니다. 또한 많은 시스템이 파일 확장자로 파일 형식을 연결하며(예: 실행 파일 연결 및 다양한 웹 캐싱 소프트웨어), 이러한 시스템은 릴리스되는 각 버전마다 업데이트해야 합니다. 더욱이 현재 휠 명세가 취약한 이유 중 하나는 너무 많은 메타데이터가 파일 이름에 저장된다는 점입니다. 파일 이름은 구조화된 데이터를 저장하는 데 적합하지 않습니다. 파일 이름에 정보를 인코딩하는 방식에서 벗어나는 것이 향후 휠 개정판의 목표가 되어야 합니다.

또 다른 가능성은 파일 확장자를 사용하여 내부 휠 버전과 별도로 외부 컨테이너 형식(즉, .dist-info를 포함하는 ZIP 파일)을 인코딩하는 것입니다. 그러나 이 경우 파일 확장자와 내부 Wheel-Version이 서로 달라지면 혼란이 발생할 수 있습니다. 설치 프로그램이 휠 메타데이터에서 얻은 호환되지 않는 휠 3.0으로 인해 오류를 발생시키면, 일부 사용자는 파일 확장자 .whl2와의 차이 때문에 혼란스러워할 것입니다.

휠 2.0에서는 외부 컨테이너 형식을 변경해야 합니다

휠 2.0에서는 휠 파일의 확장자가 변경되므로 외부 컨테이너 형식을 수정하기에 가장 좋은 기회입니다. 도구가 읽기를 선택적으로 활성화해야 하는 다른 파일 확장자와는 하위 호환성을 유지할 필요가 없습니다. 다른 외부 압축 형식을 사용하는 주된 용도는 더 나은 압축을 제공하는 것입니다. 예를 들어 외부 컨테이너를 Zstandard tar 파일인 .tar.zst로 변경할 수 있으며, 이렇게 하면 압축을 더 빠르게 해제하고 더 작은 휠을 생성할 수 있습니다. 그러나 여기에는 몇 가지 실질적인 문제가 있습니다. 우선 Zstandard는 Python 표준 라이브러리의 일부가 아니므로, 순수 Python 패키징 도구는 이러한 휠의 압축을 해제하기 위한 확장 모듈을 함께 제공해야 합니다. 이로 인해 확장 모듈을 설치하기 어려운 여러 플랫폼에서 일부 호환성 문제가 발생할 수 있습니다. 더욱이 향후 휠 개정판에서는 기존 ZIP 기반 형식 내부에 .tar.zst를 사용하는 새로운 비메타데이터 파일 레이아웃을 언제든 도입할 수 있습니다.

마지막으로 휠 파일 형식을 한 번에 지나치게 많이 변경하는 것은 좋은 생각이 아닙니다. 이 PEP의 목표는 명세를 더 쉽게 발전시키는 것이며, 휠의 발전을 더 쉽게 만들어야 하는 근거 중 하나는 “한 번에 모두” 변경하는 일을 피하는 것입니다. 휠의 외부 파일 형식을 변경하면 패키지 메타데이터를 검색할 뿐만 아니라 설치하는 방식도 다시 작성해야 합니다.

이 PEP에서 휠 2.0을 명세하지 않는 이유는 무엇입니까?

휠 2.0의 일부로 포함될 수 있는 많은 기능이 있지만, 이 PEP에서는 이를 다루지 않습니다. 이 PEP의 목표는 휠 파일 형식에 대한 호환성 방안을 정의하는 것입니다. 휠 버전 간 호환성과 관련이 없는 변경 사항은 이 PEP에 포함할 필요가 없으며, 새로운 휠 기능을 정의하는 후속 PEP에서 도입해야 합니다.

논의 주제

최초 마이그레이션을 위해 색인에서 이중 게시를 지원해야 합니까?

.whl과 .whlx는 파일 이름에서 서로 다르게 보이므로, PyPI와 같은 패키지 색인에 나란히 업로드할 수 있습니다. 이렇게 하면 이전 및 최신 설치 프로그램을 모두 지원할 수 있다는 장점이 있으므로, 최신 기능을 사용할 수 있는 사용자는 물론 업그레이드하지 않는 사용자도 패키지의 최신 버전을 설치할 수 있습니다.

그러나 여기에는 많은 복잡한 문제가 있습니다. 기존의 휠 1 전용 릴리스에 휠 2 업로드를 허용해야 합니까? 병렬 wheel에 다음과 같은 요구 사항을 두어야 할까요?

이중 게시된 wheel에 대한 제약 조건

특정 색인에는 wheel 버전이 다른 동일한 내용의 wheel이 포함될 수 있으며, 다른 모든 요소가 동일하다면 설치 프로그램은 사용 가능한 가장 최신의 wheel 형식을 선호해야 합니다.

“원자적” 이중 게시를 허용하는 PEP 694과 함께 둘 다 업로드하는 것만 허용해야 합니까?

감사의 말

이 PEP의 작성자는 Barry Warsaw와 Michael Sarahan의 매우 귀중한 검토, 조언 및 피드백에 깊이 감사드립니다.

Copyright

This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.