PEP 685 – 선택적 배포 의존성의 추가 기능 이름 비교
- Author:
- Brett Cannon <brett at python.org>
- PEP-Delegate:
- Paul Moore <p.f.moore at gmail.com>
- Discussions-To:
- Discourse thread
- Status:
- Final
- Type:
- Standards Track
- Topic:
- Packaging
- Created:
- 08-Mar-2022
- Post-History:
- 08-Mar-2022
- Resolution:
- Discourse message
번역·라이선스 안내
이 비공식 한국어 번역은 원문 Copyright 절의 Public Domain or CC0-1.0, whichever is more permissive 조건에 따라 제공합니다. 원저자와 공식 원문은 그대로 표시합니다. 수정되지 않은 기준 원문 · 공식 최신판
초록
이 PEP는 비교를 수행할 때 distribution extra이름을 정규화하는 방법을 규정합니다. 이를 통해 도구가 추가 기능 이름을 찾지 못하거나 예기치 않은 이름과 실수로 일치시키는 일을 방지합니다.
동기
Provides-Extra 핵심 메타데이터 사양은 추가 기능의 이름이 “유효한 Python 식별자여야 합니다”라고 명시합니다. PEP 508은 extra 마커의 값이 첫 문자를 제외하고 문자, 숫자 또는 ., -, _ 중 하나를 포함할 수 있다고 명시합니다. 어떻게 extra 이름을 작성하거나 비교를 위해 정규화해야 하는지를 설명하는 다른 PyPA specification은 없습니다. 패키징 관련 코드가 이미 많이 존재하므로, 현재 커뮤니티의 관행을 평가하고 기존 코드 대부분을 손상하지 않으면서 도구 작성자가 따르기로 동의할 수 있는 하나의 방식을 표준화하는 것이 중요합니다.
일관된 표준이 없다는 문제는 초기 논의에서 제기되었으며, 해당 논의에서는 pip 22가 adhoc-ssl 추가 기능을 adhoc_ssl 이름과 같다고 간주하지 않는다는 점을 지적했습니다.
근거
PEP 503은 배포 이름을 정규화하는 방법을 규정합니다.:
re.sub(r"[-_.]+", "-", name).lower()
이는 -, _, . 문자가 연속해서 나타나는 부분을 하나의 -로 축약합니다. 예를 들어 ---, . 및 __는 모두 -로 변환됩니다. 이는 핵심 메타데이터 2.2 사양에 따른 extra 이름으로서 유효한 Python 식별자를 생성하지 않습니다.
Setuptools 60은 정규화를 수행합니다 를 통해:
re.sub(r'[^A-Za-z0-9-.]+', '_', name).lower()
밑줄/_을 사용하는 점은 PEP 503에서 하이픈/-을 사용하는 것과 다르며, PEP 508에서 허용하는 문자 외의 문자도 정규화합니다. PEP 503과 달리 . 및 -의 연속은 하나의 _로 정규화되지 않으며, 예를 들어 ..는 그대로 유지됩니다. 참고로 이는 이 함수의 독스트링과 일치하지 않습니다. 독스트링에는 모든 영숫자가 아닌 문자(여기에는 -와 .도 포함됨)가 정규화되어 하나로 합쳐진다고 명시되어 있습니다.
pip 22의 경우 해당 “추가 기능 정규화 동작은 매우 복잡하고 불규칙” [pip-erratic]하므로 그 사용은 고려하지 않습니다.
사양
추가 기능 이름을 비교할 때 도구는 이름에 대해 PEP 503에 설명된 의미 체계를 사용하여 비교 대상 이름을 반드시 정규화해야 합니다.:
re.sub(r"[-_.]+", "-", name).lower()
core metadata 사양은 Provides-Extra에 허용되는 이름이 이름에 대해 PEP 508이 규정하는 내용과 일치하도록 업데이트됩니다. 이를 통해 추가 기능 이름 지정이 Name 필드의 이름 지정과 일치하게 됩니다. 유효한 것으로 간주되는 대상이 변경되므로 핵심 메타데이터 버전이 2.3으로 증가합니다.
core metadata를 작성하는 도구는 extra 이름을 정규화된 형태로 반드시 기록해야 합니다. 이는 Provides-Extra필드와 Requires-Dist필드에서 사용되는 추가 기능 마커에 적용됩니다.
메타데이터를 생성하는 도구는 사용자가 정규화할 때 동일한 이름이 되는 추가 기능 이름을 두 개 이상 지정하면 반드시 오류를 발생시켜야 합니다. 메타데이터를 생성하는 도구는 지정된 핵심 메타데이터 버전에 맞지 않는 잘못된 추가 기능 이름이 제공되면 반드시 오류를 발생시켜야 합니다. 프로젝트의 메타데이터가 이전 핵심 메타데이터 버전을 지정하고 해당 이름이 최신 핵심 메타데이터 버전에서 유효하지 않다면, 해당 메타데이터를 읽는 도구는 사용자에게 경고해야 합니다. 도구는 잘못된 추가 기능 이름을 읽으면 사용자에게 경고해야 하며 모호성을 피하기 위해 해당 이름을 무시해야 합니다. 도구는 원한다면 잘못된 이름을 읽을 때 경고 대신 오류를 발생시킬 수 있습니다.
하위 호환성입니다.
관련 PEP 503 정규화로 전환하고 PEP 508 이름 허용을 채택하면 기존의 모든 유효한 이름이 계속 유효하게 유지됩니다.
PyPI의 휠 모음을 조사한 연구에 따르면 [pypi-results], PyPI의 모든 extra 이름을 유효 여부와 관계없이 고려할 경우(단일 패키지 내의 이름만이 아님) extra 이름 충돌 위험은 73건으로 제한되지만, only 유효한 이름만 살펴보면 충돌은 3건에 불과합니다:
dev-test:dev_test,dev-test,dev.testdev-lint:dev-lint,dev.lint,dev_lintapache-beam:apache-beam,apache.beam
핵심 메타데이터를 작성하는 도구가 정규화된 이름만 기록하도록 요구하면 기존의 유효하지 않은 extra 이름 문제는 시간이 지남에 따라 줄어들 것입니다.
보안 관련 영향입니다.
충돌하는 extra 이름을 가진 배포 패키지의 경우, 도구가 어떤 방식으로든 시스템 보안을 약화하는 종속성을 설치하게 될 수 있습니다. 이는 가설에 불과하며 실제로 발생하더라도, 그러한 extra 이름을 지정한 배포 패키지 쪽의 보안 문제가 이를 함께 가져온 배포 패키지보다 더 클 가능성이 높습니다.
이 내용을 가르치는 방법입니다.
이는 사용자의 일상적인 사용 과정에서는 투명하게 처리되어야 합니다. 충돌하는 extra 이름을 선택할 때 사용자를 안내하거나 중지하는 것은 도구의 역할입니다.
참조 구현입니다.
위의 코드 외에는 참조 구현이 제공되지 않지만, packaging project가 packaging.utils 모듈에 extra 이름 정규화를 구현하는 함수를 제공할 것으로 예상합니다. 또한 extra 이름 비교도 적절하게 구현할 것입니다. 마지막으로 프로젝트가 메타데이터를 기록하는 기능을 갖추게 된다면 이 PEP도 구현할 것입니다.
전환 계획입니다.
빌드 도구가 버전 2.3, 즉 이 PEP에 부합하는 핵심 메타데이터를 생성하지만, 이를 이 PEP를 인식하지 못하는 도구가 사용하게 될 위험이 있습니다(해당 도구가 직접 지원하지 않는 핵심 메타데이터 버전을 읽으려고 시도하는 경우). 이러한 경우 사용자가 이전에는 작동했지만 이제는 실패하는 정규화되지 않은 이름을 사용하여 extra를 지정할 가능성이 있습니다.
따라서 이 PEP의 생산자보다 소비자를 우선시하여, 사용자가 정규화되지 않은 extra 이름을 지정하고 있음(따라서 향후 문제가 발생할 수 있음)을 알릴 수 있도록 해야 합니다.
거부된 아이디어입니다.
setuptools 60의 정규화 사용입니다.
처음에 이 PEP는 하위 호환성 문제를 최소화하기 위해 setuptools의 safe_extra()를 정규화에 사용하자고 제안했습니다. 그러나 PyPI의 다양한 휠을 확인한 결과, PEP 508 및 PEP 503 의미론에 따라 모든 이름 지정을 표준화하는 것이 더 쉽고 장기적으로 더 나은 방법이며, 하위 호환성 문제도 최소화한다는 점이 분명해졌습니다.
미해결 문제입니다.
해당 없음입니다.
Copyright
This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.