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는 소스 배포판에 지정된 메타데이터 값과 해당 소스 배포판에서 빌드된 휠의 대응 값 사이의 관계를 정의합니다. 빌드 백엔드는 sdist에서 wheel로 단순히 변경 없이 복사되지 않을 모든 필드를 명확히 표시해야 합니다.

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

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

소스 배포판의 메타데이터에서 발견되는 경우 다음 규칙이 적용됩니다.

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

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

소스 배포판이 아닌 모든 상황에서 필드가 Dynamic으로 표시되어 있다면, 해당 값은 휠을 빌드할 때 생성되었으며 sdist(또는 프로젝트의 다른 빌드)에 포함된 값과 일치하지 않을 수 있음을 나타냅니다. 그러나 백엔드는 이 정보를 기록할 필요가 없으며, 소비자는 소스 배포판인 경우를 제외하고 Dynamic표시가 없다는 사실에 어떠한 의미가 있다고 가정해서는 안 됩니다.

Name 및 Version 필드는 Dynamic으로 표시해서는 안 됩니다.

이 PEP는 새로운 메타데이터 필드를 추가하므로 핵심 메타데이터 형식을 버전 2.2로 업데이트합니다.

소스 배포판은 생성 시점에 제공되었던 최신 버전의 핵심 메타데이터 사양을 사용해야 합니다.

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

필드를 Dynamic으로 표시하는 대신, 명시적으로 Static으로 표시되지 않는 한 필드는 동적이라고 가정해야 합니다.
이는 현재 제안과 논리적으로 동등하지만, 필드가 동적인 것이 일반적이라는 의미를 내포합니다. 패키징 도구는 정적인 것으로 알려진 메타데이터가 있을 때 훨씬 더 효율적으로 작동할 수 있으므로, 이 PEP는 동적 필드를 예외로 만들고 백엔드가 필드를 동적으로 만드는 데 “opt in”하도록 요구합니다.

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