Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python 개선 제안 한국어 번역

PEP 658 – Simple 저장소 API에서 배포물 메타데이터 제공하기

Author:
Tzu-ping Chung <uranusjr at gmail.com>
Sponsor:
Brett Cannon <brett at python.org>
PEP-Delegate:
Donald Stufft <donald at stufft.io>
Discussions-To:
Discourse thread
Status:
Accepted
Type:
Standards Track
Topic:
Packaging
Created:
10-May-2021
Post-History:
10-May-2021
Resolution:
Discourse message
Table of Contents

번역·라이선스 안내

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

초록

이 PEP는 PEP 503 “simple” 저장소 API에서 배포물의 METADATA 파일을 노출하는 앵커 태그를 추가할 것을 제안합니다. 주어진 배포물의 해당 파일을 따로 가져올 수 있음을 나타내기 위해 data-dist-info-metadata 속성을 도입합니다.

동기

최근 도구들이 대중화한 패키지 관리 워크플로에서는 배포물을 설치할 의도 없이 배포물 메타데이터를 검사해야 하는 경우와, 메타데이터를 바탕으로 선택하기 위해 한 프로젝트의 여러 배포물을 내려받아야 하는 경우가 늘어나고 있습니다. 이 때문에 도구들은 내려받은 데이터의 상당 부분을 결국 버리게 되며, 이는 비효율적이고 나쁜 사용자 경험으로 이어집니다.

근거

도구들은 HTTP 범위 요청으로 wheel을 부분적으로 내려받아 다운로드 크기를 줄이는 방법을 모색해 왔습니다. 그러나 이 방법은 저장소 서버에 런타임 요구 사항을 추가로 부과합니다. 또한 메타데이터 파일을 가져올 정확한 오프셋을 찾으려면 wheel의 파일 목록을 가져오는 별도의 요청이 필요하므로 여전히 추가 오버헤드가 발생합니다. 따라서 추가 요청과 ZIP 검사를 할 필요가 없도록, 서버가 메타데이터 파일을 미리 추출하여 독립된 파일로 제공하게 하는 것이 바람직합니다.

코어 메타데이터 명세 [core-metadata]에 정의된 메타데이터 파일은 일반적인 사용 사례에 필요한 정보를 담고 있으므로 저장소가 이를 직접 제공합니다. 메타데이터는 wheel [wheel] 및 sdist [sdist] 같은 표준을 준수하는 배포물에 대해서만 제공되어야 하며, 배포물의 정식 메타데이터 파일(예: .dist-info 디렉터리 안에 있는 wheel의 METADATA 파일 [dist-info])과 동일해야 합니다.

클라이언트가 별도로 제공되는 메타데이터 파일을 선택할 수 있는지 나타내려면 배포 파일의 앵커 링크에 HTML 속성이 필요합니다. 이 속성은 클라이언트 측 검증을 위해 메타데이터 내용의 해시를 제공하는 데에도 사용됩니다. 이 속성이 없으면 배포물의 내용 때문이든 저장소가 지원하지 않기 때문이든 해당 배포물에 대해 별도의 메타데이터 항목을 사용할 수 없음을 나타냅니다.

명세

simple 저장소의 프로젝트 페이지에서 배포물을 가리키는 각 앵커 태그에는 data-dist-info-metadata 속성이 있을 수 있습니다(MAY). 이 속성이 있다는 것은 해당 앵커 태그가 나타내는 배포가 처리 및/또는 설치될 때 수정되지 않는 코어 메타데이터 파일을 반드시 포함한다는 뜻입니다.

data-dist-info-metadata 속성이 있으면, 저장소는 배포의 파일 이름 뒤에 .metadata를 붙인 경로로 배포와 함께 배포의 코어 메타데이터 파일을 반드시 제공해야 합니다. 예를 들어, /files/distribution-1.0-py3.none.any.whl에서 제공되는 배포의 코어 메타데이터는 /files/distribution-1.0-py3.none.any.whl.metadata에 위치합니다. 이는 PEP 503이 GPG 서명 파일의 위치를 규정하는 방식과 비슷합니다.

저장소는 <hashname>=<hashvalue> 문법을 사용하여 코어 메타데이터 파일의 해시를 data-dist-info-metadata 속성의 값으로 제공하는 것이 좋습니다. 여기서 <hashname>은 사용된 해시 함수 이름의 소문자 형태이고, <hashvalue>는 16진수로 인코딩된 다이제스트입니다. 해시를 사용할 수 없는 경우 저장소는 속성의 값으로 true를 사용할 수 있습니다(MAY).

하위 호환성

앵커 태그에 data-dist-info-metadata 속성이 없으면, 도구는 메타데이터를 검사하기 위해 배포물을 내려받는 현재 동작으로 되돌아갈 것으로 예상됩니다.

새로운 data-dist-info-metadata 속성을 지원하지 않는 이전 도구는 이 속성을 무시하고, 메타데이터를 검사하기 위해 배포물을 내려받는 현재 동작을 유지할 것으로 예상됩니다. 이는 이전에 data- 속성을 추가할 때 기존 도구가 동작하리라고 예상한 방식과 비슷합니다.

기각된 아이디어

메타데이터 내용을 프로젝트 페이지에 넣기

도구에는 일반적으로 프로젝트 페이지에서 이미 얻을 수 있는 정보 외에 배포물의 의존성 정보만 있으면 되므로, PEP 503에 명시된 data-requires-python 속성처럼 저장소가 프로젝트 페이지에 이 정보를 직접 포함할 수 있게 하자는 제안이 있었습니다.

배포 파일 하나에는 (필수 및 선택) 의존성 목록이 얼마든지 길게 들어 있을 수 있습니다. 또한 대부분의 배포 파일에 대한 정보는 일반적으로 결국 필요 없게 됩니다. 따라서 프로젝트의 모든 배포 파일에 대한 정보를 포함하는 것이 실제로 절감 효과를 가져올지 불분명하므로 이 방식은 폐기되었습니다. 메타데이터를 별도로 제공하면 데이터 사용량이 검사하는 배포 파일 수에 더 비례하게 되므로 성능을 더 잘 추정할 수 있습니다.

배포 파일의 더 많은 파일 노출

메타데이터 파일만이 아니라 .dist-info 디렉터리 전체를 별도의 부분으로 제공하자는 제안이 있었습니다. 그러나 여러 파일을 HTTP를 통해 하나의 엔터티로 제공하려면 저장소 서버가 원본 배포 파일에서 파일을 추출한 뒤 별도로 다시 아카이브해야 합니다. 또한 배포 파일 자체를 설치하지 않을 때 METADATA 이외의 파일이 필요한 사용 사례는 현재 없습니다.

또한 여기서 택한 방식은 앞으로 다른 파일을 도입하는 것을 배제하지 않는다는 점에 유의하십시오. 그러한 파일을 함께 제공하든 개별적으로 제공하든 마찬가지입니다.

프로젝트 페이지에 메타데이터 파일의 URL을 명시적으로 지정

이 초안의 초기 버전에서는 메타데이터 파일의 URL을 data-dist-info-metadata 속성에 넣자고 제안했습니다. 하지만 그 대신 저장소가 정해진 위치에서 메타데이터 파일을 제공하도록 요구하는 편이 발견 가능성 측면에서 더 낫다는 의견이 많습니다. 현재 방식에는 프로젝트 페이지가 더 작아진다는 추가 이점도 있습니다.

참고 문헌