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을 계속 사용하기
  • wheel 메이저 버전을 파일 확장자에 저장하기 (.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에 맡깁니다.

근거

현재 새로운 설치 프로그램 동작을 요구하는 wheel 명세 변경은 하위 호환성이 없으며, wheel 메타데이터 형식의 메이저 버전을 올려야 합니다. wheel 메이저 버전은 아직 한 번도 올라간 적이 없는데, 그 이유 중 하나는 그러한 변경이 파국적인 혼란을 일으킬 수 있기 때문입니다. wheel 명세에 따르면, 새 메이저 버전을 지원하지 않는 설치 프로그램은 설치 시점에 중단해야 합니다. 즉, 추가적인 계획 없이 메이저 버전을 올린다면, Python 패키지 색인(PyPI)과 같은 공개 패키지 색인에 업로드된 새 wheel을 오래된 설치 프로그램이 거부하면서 많은 사용자가 설치 실패를 겪게 됩니다. 호환성 문제를 피하려면 빌드 도구, 패키지 색인, 패키지 설치 프로그램 사이의 상호 작용을 신중하게 계획하는 것이 매우 중요하며, 설치 프로그램을 늦게 업데이트하는 사용자들의 긴 꼬리를 고려하면 더욱 그렇습니다.

하위 호환성에 대한 우려 때문에 더 나은 압축, wheel 데이터 형식 개선, wheel에 포함된 내용에 대한 더 나은 정보, “.dist-info” 폴더의 JSON 형식 메타데이터 같은 wheel 파일 형식의 가치 있는 개선이 이루어지지 못했습니다.

이 PEP는 wheel 형식의 새 메이저 버전을 지원하지 않는 기존 도구의 안정성을 유지하기 위해 새로운 wheel 개정판이 따라야 할 제약 조건과 동작을 기술합니다. 이를 통해 휠 명세의 하위 호환되지 않는 변경이 더 새로운 휠을 사용하도록 적절히 설정된 사용자와 도구에만 영향을 미치도록 보장합니다. 휠 명세를 발전시키기 위한 명확한 경로가 마련되면, 향후 PEP들은 완전히 새로운 호환성 방안을 다시 정의할 필요 없이 휠 형식을 개선할 수 있을 것입니다.

명세

코어 메타데이터에 Wheel-Version 메타데이터 필드 추가

현재 wheel 1.0 PEP인 PEP 427은 wheel 파일이 해당 파일이 따르는 wheel 명세의 버전을 담은 WHEEL 메타데이터 파일을 포함해야 한다고 규정합니다. PEP 427은 설치 프로그램이 지원하는 것보다 마이너 버전이 높은 wheel을 설치할 때는 반드시 경고해야 하고, 설치 프로그램이 지원하는 것보다 메이저 버전이 높은 wheel을 설치할 때는 반드시 중단해야 한다고 명시합니다. 이를 통해 사용자는 설치 프로그램이 제대로 설치할 수 없는 wheel로 인해 잘못된 설치 결과를 얻지 않게 됩니다.

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

이를 위해 Wheel-Version이라는 새 필드가 핵심 메타데이터 명세에 추가됩니다. 이 필드는 한 번만 사용할 수 있으며, WHEEL 파일 또는 향후 wheel 파일에 대한 메타데이터를 정의하는 대체 파일의 Wheel-Version 항목에 지정된 것과 정확히 같은 버전을 담아야 합니다. 메타데이터 파일에 Wheel-Version이 없으면, 도구는 wheel 파일의 메이저 버전을 반드시 1로 추론해야 합니다.

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

Wheel-Version은 버전 1 휠의 메타데이터 파일에 포함될 수 있지만, 버전 2 이상의 휠에서는 메타데이터 파일에 Wheel-Version이 반드시 포함되어야 합니다. 이를 통해 향후 휠 명세 개정판은 리졸버가 Wheel-Version 필드를 검사하여 호환되지 않는 휠을 건너뛴다는 점을 전제로 삼을 수 있습니다. 빌드 백엔드는 버전과 관계없이 자신이 생성하는 모든 휠에 Wheel-Version을 포함하는 것이 권장됩니다.

설치 프로그램은 설치 중에 wheel 안의 메타데이터 파일을 수정하지 않고 그대로 복사하는 것이 권장됩니다. 이렇게 하면 오류가 발생하기 쉬운 작업인 RECORD 파일 갱신이 필요 없어집니다. 설치된 코어 메타데이터를 읽는 도구는 다른 설치 형식에서는 이 필드가 생략될 수 있으므로, 이 필드가 존재한다고 가정하지 않는 것이 좋습니다.

wheel을 설치할 때 설치 프로그램은 반드시 다음 단계를 따라야 합니다.

1. 코어 메타데이터 파일과 휠 메타데이터 파일 양쪽의 Wheel-Version 값이 일치하는지 확인합니다. 두 값이 일치하지 않으면 설치 프로그램은 반드시 설치를 중단해야 합니다. 어느 쪽 값도 우선하지 않습니다.
2. 설치 프로그램이 Wheel-Version과 호환되는지 확인하십시오. Wheel-Version이 없으면 버전을 1.0으로 간주합니다. 마이너 버전이 더 크면 경고하고, 메이저 버전이 더 크면 중단합니다. 이 절차는 PEP 427의 절차와 동일합니다.
3. Binary Distribution Format 명세에 규정된 대로 설치를 진행합니다.

Wheel-Version에 관한 리졸버 동작

리졸버는 설치할 wheel을 선택하는 과정에서 후보 wheel의 Wheel-Version을 반드시 확인하고, 호환되지 않는 wheel 파일은 무시해야 합니다. 이러한 파일을 무시하지 않으면, 오래된 설치 프로그램이 자신이 지원하지 않는 wheel 버전을 사용하는 wheel을 선택하게 되어 PEP 427에 따라 설치 프로그램이 중단될 수 있습니다. 호환되지 않는 wheel 파일을 건너뛰면, 프로젝트가 새 wheel 메이저 버전을 채택하더라도 사용자는 설치 오류를 겪지 않게 됩니다. PEP 427에 이미 명시된 대로, 사용자가 호환되지 않는 wheel을 직접 설치하려고 하면 설치 프로그램은 반드시 중단해야 합니다. 여러 색인에서 찾은 패키지를 해석하는 과정에서 리졸버가 같은 배포 패키지, 같은 버전의 휠 두 개를 만나면, 리졸버는 호환되는 가장 높은 버전의 휠을 우선해야 합니다.

위의 방식은 예기치 않은 문제로부터 사용자를 보호하지만, 사용자의 설치 프로그램이 해당 릴리스에서 사용된 wheel 버전을 지원하지 않는다면 사용자는 배포의 새 릴리스를 놓칠 수 있습니다. 향후 어떤 패키지가 3.0 wheel 파일을 게시한다고 가정해 봅시다. 다운스트림 사용자의 설치 프로그램이 2.x wheel만 지원한다면, 그 사용자는 새 릴리스가 나왔다는 사실을 알 수 없습니다. 따라서 설치 프로그램은 패키지를 해석하는 과정에서 호환되지 않는 wheel을 발견하여 건너뛸 경우 경고를 내보내는 것이 권장됩니다.

첫 메이저 버전 상향 시 파일 확장자 변경 필수

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

기각된 대안 중 하나는 .whl 확장자를 유지하되 휠 2.0을 PyPI에 게시하는 시점을 늦추는 것입니다. 이에 관한 자세한 내용은 기각된 아이디어를 참조하십시오.

새 휠 형식에 대한 빌드 백엔드 권장 동작

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

향후 휠 개정에 대한 제약

휠 형식에 앞으로 어떤 기능이 계획될지 알기는 어렵지만, 특정한 호환성 약속을 유지하는 것은 중요합니다.

설치된 wheel 파일은 지원되는 모든 CPython 버전에서 Python 표준 라이브러리의 importlib.metadata와 반드시 호환되어야 합니다. 예를 들어, .dist-info/METADATA를 JSON 형식의 메타데이터 파일로 대체하는 작업은 반드시 여러 메이저 버전에 걸친 마이그레이션이어야 합니다. 한 버전에서는 기존 이메일 헤더 형식과 함께 새 JSON 파일을 도입하고, 이후의 다른 버전에서 이메일 헤더 형식의 메타데이터 파일을 제거해야 합니다. 또한 .dist-info/METADATA를 제거하는 버전은 새 파일을 지원하지 않던 마지막 CPython 릴리스의 지원이 종료된 이후에만 반드시 도입되어야 합니다. 이를 통해 importlib.metadata를 사용하는 코드가 휠 메이저 버전 개정으로 인해 동작하지 않게 되는 일이 없도록 보장합니다.

wheel 파일은 외부 컨테이너 형식으로 반드시 ZIP 형식 파일을 유지해야 합니다. 또한 .dist-info 메타데이터 디렉터리는 반드시 압축 없이 아카이브의 루트에 위치해야 합니다. 그래야 wheel 파일의 압축을 풀었을 때 wheel의 모든 메타데이터를 담은 일반적인 .dist-info 디렉터리가 만들어집니다. 향후 휠 개정에서는 데이터와 코드처럼 메타데이터가 아닌 휠 구성 요소의 레이아웃, 압축 및 기타 속성을 수정할 수 있습니다. 이를 통해 향후 휠 개정은 압축 도입과 같은 휠 내 코드 저장 방식의 개선을 허용하면서도, 패키지 메타데이터를 다루는 도구와의 호환성을 유지하게 됩니다.

패키지 도구는 메타데이터 폴더 내용과 외부 컨테이너 형식에 관한 위의 제약 외에는, 향후 wheel 메이저 버전에서도 wheel 파일의 내용과 형식이 그대로 유지된다고 가정해서는 안 됩니다. 예를 들어, 더 새로운 휠 메이저 버전에서는 빌드 태그나 플랫폼 태그와 같은 파일 이름 구성 요소를 추가하거나 제거할 수 있습니다. 따라서 도구는 휠을 설치하려고 시도하기 전에 메타데이터에서 Wheel-Version을 확인할 책임이 있습니다.

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

하위 호환성

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

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

이 PEP는 또한 향후 휠 리비전에 대한 제약 조건을 정의하며, 그 목표는 CPython과의 호환성을 유지하면서도 휠 내용물의 발전을 허용하는 것입니다. 휠 리비전 때문에 이전 CPython 리비전에서 패키지 설치가 깨져서는 안 됩니다. 그런 일은 짜증스러울 뿐만 아니라 사용자가 디버깅하기도 매우 어렵기 때문입니다.

이 PEP는 리졸버가 대개 PEP 658을 통해 패키지 메타데이터를 효율적으로 얻을 수 있다는 점에 의존합니다. 이는 PEP 658 메타데이터를 제공하지 않는 패키지 색인의 사용자에게 문제가 될 수 있습니다. 그러나 현재 대부분의 설치 프로그램은 대체 수단으로 HTTP 범위 요청을 사용해 메타데이터를 읽는 데 필요한 wheel의 일부만 효율적으로 가져옵니다. 이는 대부분의 스토리지 제공자와 서버가 지원하는 기능입니다. 게다가 압축과 같은 향후 휠 개선 사항이 휠 안의 파일을 검사하는 데 따르는 성능 손실을 만회할 것입니다.

이 PEP의 주된 호환성 제약은 소스 배포판과 함께 새 휠만 게시하기 시작하는 프로젝트에 해당합니다. 구버전 설치 프로그램을 쓰는 사용자가 패키지를 설치하려고 하면, 리졸버가 새로운 wheel을 모두 건너뛰기 때문에 소스 배포판으로 대체됩니다. 사용자는 소스에서 프로젝트를 빌드할 환경을 제대로 갖추지 못한 경우가 많으므로, 이로 인해 그렇지 않았다면 겪지 않았을 빌드 실패가 발생할 수 있습니다. 이 문제를 해결하는 방법에는 초기 이전 기간 동안 이중 게시를 허용하거나 소스 배포판을 빌드용이 아닌 것으로 표시하는 등 여러 가지가 있습니다.

기각된 아이디어

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

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

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

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

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

.whl 확장자를 유지하는 것은 여러 이유로 매력적이지만, 극복하기 어려운 몇 가지 문제가 있습니다. 첫째, 현재 설치 프로그램은 여전히 새 wheel을 선택하고 패키지 설치에 실패할 것입니다. 또한 정해진 wheel 파일 이름 형식을 기대하는 기존 설치 프로그램을 망가뜨리지 않고는 wheel의 파일 이름을 바꿀 수 없습니다. 현재의 휠 파일 이름 명세는 지금의 용도에는 충분하지만, 파일 이름 중간에 있는 선택적 빌드 태그 때문에 어떤 확장이든 모호해집니다(즉, foo-0.3-py3-none-any-fancy_new_tag.whl은 빌드 태그가 py3인 것으로 파싱됩니다). 이 때문에 wheel 파일 이름에 저장되는 정보를 바꾸는 데 제약이 생깁니다.

wheel 메이저 버전을 파일 확장자에 저장하기 (.whl2)

wheel 메이저 버전을 파일 확장자에 저장하는 방식에는 몇 가지 좋은 장점이 있습니다. 우선, 설치 프로그램이 파일 확장자만 보고 걸러낼 수 있으므로 Wheel-Version 메타데이터 필드를 도입할 필요가 없습니다. 또한 향후 여러 버전의 패키지를 나란히 두는 것도 가능해집니다. 그러나 메이저 버전마다 wheel의 확장자를 바꾸는 데에는 몇 가지 단점이 있습니다. 첫째, WHEEL 파일에 저장된 버전이 파일 확장자와 일치해야 하며, 설치 프로그램이 이를 검증해야 합니다. 또한 많은 시스템이 파일 확장자로 파일 유형을 연결하는데(예: 실행 파일 연결, 각종 웹 캐싱 소프트웨어), 새 버전이 릴리스될 때마다 이들을 갱신해야 합니다. 게다가 현재 휠 명세가 취약한 이유 중 하나는 너무 많은 메타데이터가 파일 이름에 저장된다는 점입니다. 파일 이름은 구조화된 데이터를 저장하기에 적합하지 않습니다. 파일 이름에 정보를 인코딩하는 방식에서 벗어나는 것이 향후 휠 개정의 목표가 되어야 합니다.

또 다른 방법은 파일 확장자로 내부 휠 버전과는 별개로 외부 컨테이너 형식(즉, .dist-info를 담은 ZIP 파일)을 나타내는 것입니다. 하지만 이 경우 파일 확장자와 내부 Wheel-Version이 서로 달라지면 혼란이 생길 수 있습니다. wheel 메타데이터에서 얻은 정보상 wheel 3.0과 호환되지 않아 설치 프로그램이 오류를 발생시키면, 일부 사용자는 파일 확장자 .whl2와 버전이 달라 혼란을 겪을 것입니다.

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

wheel 2.0은 wheel 파일의 확장자를 바꿀 것이므로, 외부 컨테이너 형식을 수정할 가장 좋은 기회입니다. 도구가 명시적으로 읽기를 선택해야 하는 다른 파일 확장자를 사용하므로 호환성을 유지할 필요가 없습니다. 다른 외부 압축 형식을 사용하려는 주된 이유는 더 나은 압축일 것입니다. 예를 들어 외부 컨테이너를 Zstandard tar 파일인 .tar.zst로 바꿀 수 있으며, 이렇게 하면 압축 해제가 더 빨라지고 휠 크기도 더 작아집니다. 하지만 여기에는 몇 가지 현실적인 문제가 있습니다. 첫째, Zstandard는 Python 표준 라이브러리에 포함되어 있지 않으므로, 순수 Python 패키징 도구는 이러한 휠의 압축을 풀기 위한 확장 모듈을 함께 배포해야 합니다. 이 때문에 확장 모듈을 설치하기 어려운 여러 플랫폼에서 호환성 문제가 생길 수 있습니다. 게다가 향후 휠 개정에서는 언제든 기존 ZIP 기반 형식 안에 .tar.zst를 사용하는 비메타데이터 파일의 새로운 레이아웃을 도입할 수 있습니다.

마지막으로, wheel 파일 형식을 한 번에 너무 많이 바꾸는 것은 좋은 생각이 아닙니다. 이 PEP의 목표는 명세를 더 쉽게 발전시키는 것이며, 휠을 더 쉽게 발전시키려는 근거 중 하나는 “한꺼번에” 바꾸는 일을 피하는 것입니다. 휠의 외부 파일 형식을 바꾸면 패키지 메타데이터를 찾는 방식뿐 아니라 설치하는 방식까지 다시 작성해야 합니다.

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

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

논의 주제

첫 번째 마이그레이션에서 색인이 이중 게시를 지원해야 합니까?

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

그러나 여러 가지 복잡한 문제가 있습니다. wheel 1만 있는 기존 릴리스에 wheel 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.