PEP 643 – 패키지 소스 배포판의 메타데이터

Author:: Paul Moore <p.f.moore at gmail.com>
BDFL-Delegate:: Paul Ganssle <paul at ganssle.io>
Discussions-To:: Discourse thread
Status:: Final
Type:: Standards Track
Topic:: Packaging
Created:: 24-Oct-2020
Post-History:: 24-Oct-2020, 01-Nov-2020, 02-Nov-2020, 14-Nov-2020
Resolution:: Discourse message

Table of Contents

초록
동기
근거
명세
하위 호환성
보안 영향
교육 방법
기각된 아이디어
미해결 문제
참고 문헌
Copyright

번역·라이선스 안내

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

Important

This PEP is a historical document. The up-to-date, canonical spec, Core metadata specifications, is maintained on the PyPA specs page.

See the PyPA specification update process for how to propose changes.

초록

Python 패키지 메타데이터는 Core Metadata Specification에 정의된 표준 형식으로 배포 파일에 저장됩니다. 그러나 소스 배포판은 데이터의 형식은 정의되어 있지만, 소스 배포판에 어떤 데이터를 기록하는지에 대해서는 전통적으로 일관성이 크게 부족했습니다. 이 문제에 대한 논의는 여기를 참고하십시오.

그 결과 메타데이터 소비자는 소스 배포판에서 얻을 수 있는 데이터를 신뢰할 수 없으며, 메타데이터를 추출하려면 (비용이 큰) PEP 517 빌드 메커니즘을 사용해야 합니다.

이 PEP는 빌드 백엔드가 소스 배포판에 패키지 메타데이터를 신뢰성 있게 저장할 수 있게 하면서도, 빌드 시점에 계산해야 하는 메타데이터 필드를 처리하는 데 필요한 유연성은 유지하는 표준을 정의합니다.

동기

현재 소스 배포판에 메타데이터를 저장하는 방식에는 여러 가지 문제가 있습니다:

메타데이터를 저장하는 방법의 세부 사항은 표준화되어 있기는 하지만 찾기가 쉽지 않습니다.
이 명세는 오래된 메타데이터 버전을 요구하며, 코어 메타데이터 명세의 변경 사항에 맞추어 갱신되지 않았습니다.
명세에는 “이 필드는 빌드 시점까지 값을 알 수 없으므로 생략되었음”과 “이 필드에는 값이 없음”을 구별할 방법이 없습니다.
코어 메타데이터 명세는 대부분의 필드를 선택 사항으로 허용하므로, 앞의 문제는 거의 모든 메타데이터 필드에 영향을 미칩니다.

이 PEP는 “나중에 채워질” 것으로 예상되는 필드를 기록할 수 있도록 메타데이터 명세를 갱신하고, 백엔드가 해당 버전(또는 그 이후 버전)의 명세를 사용하여 sdist 메타데이터를 기록해야 함을 명확히 하도록 소스 배포판 명세를 갱신할 것을 제안합니다.

근거

이 PEP는 프로젝트가 소스 배포판 메타데이터 값을 “동적”으로 정의할 수 있도록 합니다. 이 맥락에서 필드가 “동적”이라는 것은 소스 배포판이 생성된 시점에 그 값이 확정되지 않았다는 뜻입니다. 동적 값은 휠이 생성되는 시점에 빌드 백엔드가 제공하며, 빌드 환경의 세부 사항에 따라 달라질 수 있습니다.

PEP 621에도 “나중에 채워질” “동적” 값이라는 비슷한 개념이 있으므로, 여기서도 이에 빗대어 같은 용어를 사용하기로 합니다.

명세

이 PEP는 소스 배포판에 지정된 메타데이터 값과, 그 소스 배포판으로 빌드한 휠의 해당 값 사이의 관계를 정의합니다. 이 PEP는 빌드 백엔드가 sdist에서 휠로 변경 없이 그대로 복사되지 않는 모든 필드를 명확하게 표시하도록 요구합니다.

또한 이 PEP는 PyPA Specifications 문서를 소스 배포판 형식 명세의 정식 위치로 삼습니다(PEP 517과 이 PEP의 정보를 모아 둡니다).

새로운 필드인 Dynamic이 Core Metadata Specification에 추가됩니다. 이 필드는 여러 번 사용할 수 있으며, 다른 코어 메타데이터 필드의 이름을 담을 수 있습니다.

소스 배포판의 메타데이터에 이 필드가 있으면 다음 규칙이 적용됩니다:

필드가 Dynamic으로 표시되어 있지 않으면, sdist로 빌드한 모든 휠에서 해당 필드의 값은 sdist의 값과 반드시 일치해야 합니다(MUST). 필드가 sdist에 없고 Dynamic으로 표시되어 있지도 않으면, 해당 필드는 휠에 존재해서는 안 됩니다(MUST NOT).
필드가 Dynamic으로 표시되어 있으면, sdist로 빌드한 휠에서 해당 필드는 어떤 유효한 값이든 가질 수 있습니다(아예 존재하지 않는 경우도 포함합니다).
백엔드는 필드가 빌드 시점에 변경되지 않을 데이터로부터 생성되었다고 판단할 수 있는 경우, 해당 필드를 Dynamic으로 표시해서는 안 됩니다(MUST NOT).

백엔드는 Dynamic으로 표시한 필드에 대해 계산한 값을 소스 배포판에 기록할 수 있습니다(MAY). 그러나 소비자는 이 값을 정식 값으로 취급해서는 안 되며(MUST NOT), 휠의 최종 값이 무엇일지에 대한 힌트로 사용할 수는 있습니다(MAY).

소스 배포판이 아닌 모든 맥락에서 필드가 Dynamic으로 표시되어 있다면, 이는 해당 값이 wheel 빌드 시점에 생성되었으며 sdist(또는 프로젝트의 다른 빌드)에 있는 값과 일치하지 않을 수 있음을 나타냅니다. 다만 백엔드가 이 정보를 반드시 기록해야 하는 것은 아니며, 소비자는 소스 배포판인 경우를 제외하고는 Dynamic 표시가 없다는 사실에 어떤 의미가 있다고 가정해서는 안 됩니다(MUST NOT).

Name과 Version 필드는 Dynamic으로 표시해서는 안 됩니다(MUST NOT).

이 PEP는 새로운 메타데이터 필드를 추가하므로 코어 메타데이터 형식을 버전 2.2로 갱신합니다.

소스 배포판은 생성될 당시 사용할 수 있었던 최신 버전의 코어 메타데이터 명세를 사용해야 합니다(SHOULD).

빌드 백엔드는 꼭 필요한 경우에만 필드를 Dynamic으로 표시하고, 프로젝트가 Dynamic을 사용해야 하는 백엔드 기능을 피하도록 권장할 것을 강력히 권장합니다. 프로젝트는 설치 위치의 세부 사항에 맞추기 위해 정적 값에 환경 마커를 사용하는 방식을 우선해야 합니다.

필드를 Dynamic으로 표시하는 대신, Static으로 명시적으로 표시되지 않은 필드는 동적인 것으로 간주해야 한다는 아이디어입니다.
이는 현재 제안과 논리적으로 동등하지만, 필드가 동적인 것이 일반적인 경우라는 의미를 내포합니다. 패키징 도구는 정적임이 알려진 메타데이터가 있을 때 훨씬 더 효율적으로 동작할 수 있으므로, 이 PEP는 동적 필드를 예외로 두고 백엔드가 필드를 동적으로 만들려면 “옵트인”하도록 요구하는 방식을 택했습니다.

또한 동적인 것이 기본값이라면, 앞으로 점점 더 많은 메타데이터가 정적으로 바뀜에 따라 메타데이터 파일에 포함되는 Static 선언의 수가 계속 늘어나게 됩니다.
Dynamic 필드를 두는 대신, 필드가 “아직 정의되지 않았음”을 나타내는 특수한 값을 추가하자는 아이디어입니다.
이 역시 현재 제안과 논리적으로 동등합니다. 이 방식은 “동적임”을 명시적인 선택으로 만들지만, 특수한 값이 필요합니다. 일부 필드는 임의의 텍스트를 담을 수 있으므로 그러한 값을 고르는 것은 다소 까다롭습니다(실제로는 문제가 되지 않을 가능성이 높지만). 제안된 메커니즘 대신 이 방식을 사용할 만큼 충분한 이점은 없는 것으로 보입니다.
Requires-Python의 특별 처리.
이 PEP의 초기 초안에서는 Requires-Python에 대한 별도의 논의가 필요했습니다. 이 필드에는 환경 마커가 없어서 이 필드를 정적으로 요구하기 어려울 수 있었기 때문입니다. 동적으로 지정할 수 있는 필드의 화이트리스트라는 아이디어가 폐기되었으므로, 최종 형태의 PEP에서는 더 이상 이 논의가 필요하지 않습니다.
Dynamic의 사용을 허용된 필드의 최소한의 “화이트리스트”로 제한하자는 아이디어입니다.
이 방식은 setuptools 인터페이스의 동적인 특성 때문에 setuptools가 하위 호환성을 유지하면서 구현하기가 극도로 어려울 가능성이 높았습니다. 그 대신 현재 제안은 대부분의 필드가 동적일 수 있도록 허용하되, 꼭 필요한 경우가 아니라면 백엔드가 동적 값을 피하도록 권장합니다.