[Draft] PEP 766 - Explicit Priority Choices Among Multiple Indexes

원문 링크: PEP 766 - Explicit Priority Choices Among Multiple Indexes

상태: Draft 유형: Informational 작성일: 18-Nov-2024

PEP 766: 여러 인덱스 간 명시적 우선순위 선택 (Explicit Priority Choices Among Multiple Indexes)

요약 (Abstract)

패키지 해결(package resolution)은 Python의 핵심 기능을 확장하는 수단으로서 Python 사용자 경험의 중요한 부분입니다. 패키지 인스톨러(package installer)가 예상치 못한 동작을 할 때까지는 패키지 해결 경험은 당연하게 여겨집니다. 여러 인덱스를 사용하는 인스톨러의 동작은 예상치 못한 동작의 일반적인 원인이었습니다. pip은 그 보편성을 통해 오랫동안 생태계 내 다른 도구들의 표준적인 예상 동작을 정의해왔지만, Python 인스톨러들은 여러 인덱스를 처리하는 방식에 있어 차이를 보이고 있습니다. 이러한 차이의 핵심은 배포본(distributions)을 해결하기 전에 인덱스 내용을 결합할지, 아니면 각 인덱스를 순서대로 개별적으로 처리할지 여부입니다. pip은 배포본을 일치시키기 전에 모든 인덱스를 병합하는 반면, uv는 다음 인덱스로 넘어가기 전에 하나의 인덱스에서 배포본을 일치시킵니다. 각 접근 방식은 장단점을 가지고 있습니다. 이 PEP는 이러한 두 가지 동작(“버전 우선순위(version priority)” 및 “인덱스 우선순위(index priority)”로 지칭)을 설명하여 커뮤니티 토론 및 문제 해결이 공통된 어휘를 공유하고, 도구들이 이러한 설명에 기반하여 예측 가능한 동작을 구현할 수 있도록 하는 것을 목표로 합니다.

동기 (Motivation)

Python 패키지 사용자들은 PyPI 외의 인덱스 또는 패키지 소스를 지정해야 하는 경우가 빈번합니다. 외부 인덱스가 존재하는 이유는 다양합니다.

  • PyPI의 파일 크기/할당량 제한
  • PyTorch의 다양한 GPU 라이브러리 빌드와 같은 구현 변형
  • 조직 내에서 내부적으로 공유되는 패키지의 로컬 빌드
  • 로컬 패키지가 원격 종속성을 가지고 있고, 사용자가 필요할 때 원격 종속성으로 폴백(fall back)하면서도 로컬 패키지를 우선순위로 두기를 원하는 상황

이러한 경우 대부분 PyPI를 완전히 포기하는 것은 바람직하지 않습니다. 대신 사용자들은 일반적으로 PyPI가 여전히 패키지 소스이되, 더 낮은 우선순위 소스가 되기를 원합니다. 불행히도 pip의 현재 설계는 이러한 우선순위 개념을 배제합니다. 일부 Python 인스톨러 도구(예: uv 및 PDM)는 인덱스 우선순위를 표현하는 메커니즘을 통합한, 여러 인덱스를 처리하는 대안적인 방식을 개발했습니다.

혁신과 사용자 정의(customization)의 잠재력은 흥미롭지만, 이는 이미 Python의 약점 중 하나로 인식되는 Python 패키징 생태계를 더욱 파편화할 위험을 수반합니다. 이 PEP의 동기는 인스톨러들이 여러 인덱스를 처리하는 방식에 대한 더 많은 통찰력을 제공하고, 더 넓은 커뮤니티에서 공통적으로 사용할 수 있는 어휘를 제공하도록 장려하는 것입니다.

사양 (Specification)

“버전 우선순위” (Version priority)

이 동작은 인스톨러가 패키지가 어느 인덱스에서 오는지와 관계없이 항상 패키지의 “최고” 버전을 가져오는 것으로 특징지어집니다. “최고”는 패키지의 다양한 특성을 최적화하고 사용자 입력(예: 바이너리만 선호하거나 바이너리 없음)을 고려하는 인스톨러의 알고리즘에 의해 정의됩니다. 인스톨러마다 최적화 기준과 사용자 옵션이 다를 수 있지만, 모든 버전 우선순위 인스톨러가 공유하는 일반적인 특성은 후보 선택 전에 인덱스 내용이 정리(collated)된다는 것입니다.

버전 우선순위는 구성된 모든 인덱스가 배포본 상호 교환성(distribution interchangeability) 가정에 대해 동등하게 신뢰할 수 있고 잘 동작할 때 가장 유용합니다. 미러(mirror)는 이 점에서 특히 잘 동작합니다. 이러한 상호 교환성 가정이 특정 패키지의 배포본을 비교하는 것을 의미 있게 만듭니다. 이것이 없으면 인스톨러는 더 이상 “사과를 사과와” 비교하는 것이 아닙니다. 실제로는 다른 인덱스에 특수 하드웨어용 빌드 또는 동일한 패키지에 대한 다른 메타데이터와 같이 다른 내용의 파일이 있는 경우가 흔합니다. 버전 우선순위 동작은 이러한 경우에 바람직하지 않고 예상치 못한 결과를 초래할 수 있으며, 이럴 때 사용자들은 일반적으로 어떤 종류의 인덱스 우선순위를 찾습니다. 또한 인덱스 간에 신뢰 수준에 차이가 있을 때, 버전 우선순위는 덜 신뢰할 수 있는 인덱스보다 더 신뢰할 수 있는 인덱스를 선호하는 방법을 제공하지 않습니다. 이것은 종속성 혼란 공격(dependency confusion attacks)에 악용되어 왔으며, PEP 708은 신뢰할 수 있는 외부 인덱스 개념을 인덱스에 하드코딩하는 방법으로 제안되었습니다.

“버전 우선순위”라는 이름은 새로운 용어이며, 새로운 용어 도입은 항상 최소화되어야 합니다. 이 PEP는 버전 우선순위 동작의 구현을 “unsafe-best-match”라고 지칭하는 uv 프로젝트를 참고합니다. 여기서 이름 지정은 정말 어렵습니다. 한편으로는 pip의 기본 동작을 본질적으로 “안전하지 않다(unsafe)”고 부르는 것은 정확하지 않습니다. 잠재적으로 악성 인덱스의 추가가 이 동작에 대한 우려를 야기합니다. PEP 708은 인스톨러가 예상치 못한, 잠재적으로 안전하지 않은 인덱스에서 패키지를 가져오는 것을 제한하는 방법을 추가했습니다. 다른 한편으로는 “best-match”라는 용어는 기술적으로는 정확하지만 오해의 소지가 있습니다. “최고의 일치(best match)”는 사용자 및 애플리케이션에 따라 다릅니다. “최고”는 위에서 지정된 일치 기준에 따라 전역 최적(global optimum)이라는 의미에서 기술적으로 정확하지만, 사용자 눈에는 반드시 “최고”가 아닐 수도 있습니다. “버전 우선순위”는 uv 용어의 우려를 피하면서, 패키지가 비교되는 방식에서 가장 사용자가 식별하기 쉬운 방식으로 동작을 근사하는 제안된 용어입니다.

“인덱스 우선순위” (Index priority)

인덱스 우선순위에서 해결사(resolver)는 각 인덱스에 대해 한 번에 하나씩 후보를 찾습니다. 해결사는 현재 패키지 요청에 유효한 후보가 없는 경우에만 다음 인덱스로 진행합니다. 인덱스 우선순위는 인덱스를 하나의 전역적이고 평면적인 이름 공간으로 결합하지 않습니다. 인덱스가 순서대로 검색되기 때문에, 나중 인덱스에 인스톨러의 최적화 기준에 더 잘 맞는 일치가 있더라도, 이전 인덱스의 패키지가 선호됩니다. 주어진 인스톨러에 대해 최적화 기준 및 선택 알고리즘은 인덱스 우선순위와 버전 우선순위 모두에서 동일해야 합니다. 차이점은 여러 인덱스를 처리하는 방식에만 있습니다: 버전 우선순위는 모두 함께, 인덱스 우선순위는 개별적으로 처리합니다.

인덱스 지정 순서가 검색 과정에서의 우선순위를 결정합니다. 결과적으로 인스톨러가 인덱스 구성을 로드하는 방식은 예측 가능하고 재현 가능해야 합니다. 이 PEP는 인스톨러가 소스 컬렉션의 순서를 지정하는 방법을 제공해야 한다는 것 외에는 특정 메커니즘을 규정하지 않습니다. 또한 인스톨러는 어떤 인덱스가 고려되고 있는지에 대한 통찰력을 제공하는 선택적 디버깅 출력을 제공해야 합니다.

각 패키지의 탐색기(finder)는 인덱스 목록의 시작부터 시작해야 하므로, 각 패키지는 인덱스 목록을 처음부터 다시 시작합니다. 즉, 한 패키지가 첫 번째 인덱스에 유효한 후보가 없지만 두 번째 인덱스에서 일치하는 것을 찾았더라도, 후속 패키지는 두 번째 인덱스에서 시작하는 대신 첫 번째 인덱스에서 검색을 시작해야 합니다.

인덱스 우선순위 전략이 의미하는 바람직한 동작 중 하나는 “예상치 못한” 업데이트가 없다는 것입니다. 여기서 낮은 우선순위 인덱스의 버전 업데이트가 큐레이트되고 승인된 높은 우선순위 인덱스보다 우선하는 경우가 발생하지 않습니다. 이는 PEP 708의 보안 개선과 관련이 있습니다. PEP 708은 패키지가 배포본이 나올 수 있는 외부 인덱스를 제한할 수 있도록 하지만, 인덱스 우선순위는 최종 사용자가 더 많이 구성할 수 있습니다. 패키지 설치는 높은 우선순위 인덱스 또는 인덱스 우선순위 구성이 변경될 때만 변경될 것으로 예상됩니다. 이러한 안정성과 예측 가능성은 인덱스를 단일 설치 명령에 대한 일회성 인자(argument) 대신 환경의 보다 영구적인 속성으로 구성하는 것을 더 실행 가능하게 만듭니다.

캐시 키 (Cache keys)

인덱스 우선순위는 특정 패키지에 대해 다른 인덱스가 다른 콘텐츠를 가질 가능성을 인정하므로, 캐싱 및 lockfile은 이제 배포본이 다운로드된 인덱스를 포함해야 합니다. 이 측면이 없으면, 구성된 인덱스 목록을 변경한 후 캐시 또는 lockfile이 낮은 우선순위 인덱스에서 유사한 이름의 배포본을 제공할 수 있습니다. 모든 인덱스가 주어진 파일 이름에 대해 인덱스 간에 동일한 파일을 제공하는 권장 동작을 따른다면 이것은 문제가 되지 않습니다. 그러나 이 권장 사항은 쉽게 강제할 수 없으며, 캐시 키에 원본 인덱스를 추가하는 것은 현명한 방어적 변경이 될 것입니다.

요청이 낮은 우선순위 인덱스로 폴백(Fall through)되는 방식

다음과 같은 경우에 요청이 낮은 우선순위 인덱스로 폴백될 수 있습니다.

  • 높은 우선순위 인덱스에 패키지 이름이 전혀 없는 경우
  • 버전 지정자(version specifier), 호환되는 Python 버전, 플랫폼 태그, 얀킹(yanking) 등으로 인해 높은 우선순위 인덱스의 모든 배포본이 필터링된 경우
  • 인스톨러의 denylist 구성이 특정 패키지 이름이 주어진 인덱스에서 무시되어야 한다고 지정하는 경우
  • 높은 우선순위 인덱스에 연결할 수 없는 경우 (예: 방화벽 규칙에 의해 차단, 유지보수로 인해 일시적으로 사용할 수 없음, 기타 잡다하고 일시적인 네트워크 문제). 이는 사용자가 제어할 수 있어야 하는 덜 명확한 세부 사항입니다. 한편으로는 이 동작이 예상치 못하게 낮은 우선순위 인덱스로 폴백되어 예측 불가능하고 재현 불가능한 결과를 초래할 수 있습니다. 다른 한편으로는, 모든 인덱스가 동등하게 신뢰할 수 있다고 안전하게 가정할 수 있다면, 일부 사용자에게는 우아한 폴백(graceful fallback)이 더 가치 있을 수 있습니다. pip의 현재 동작은 우아한 폴백입니다: 인덱스에 연결 문제가 발생하면 경고가 표시되지만, 설치는 다른 사용 가능한 인덱스로 진행됩니다. 인덱스 우선순위는 인덱스 간에 다른 신뢰 수준을 전달할 수 있으므로, 인덱스 우선순위를 구현하는 인스톨러는 네트워크 문제 발생 시 기본적으로 오류를 발생시키고 중단해야 합니다. 인스톨러는 네트워크 오류 발생 시 낮은 우선순위 인덱스로 폴백을 허용하는 플래그를 제공하도록 선택할 수 있습니다.

주어진 인덱스 내에서의 처리는 기존 동작을 따르지만, 하나의 인덱스 범위 내에서 멈추고 하나의 인덱스 내의 모든 우선순위 선호도가 소진된 후에만 다음 인덱스로 넘어갑니다. 이는 통합된 패키지 컬렉션 내의 기존 우선순위가 낮은 우선순위 인덱스로 폴백하기 전에 각 인덱스에 개별적으로 적용됨을 의미합니다.

최적화 기준의 모든 수준에서 절충(tradeoff)이 있습니다.

  • 버전 (version): 인덱스 우선순위는 다른 인덱스에 더 새로운 버전이 있더라도 높은 우선순위 인덱스에서 더 오래된 버전을 사용합니다.
  • wheel vs sdist: 인스톨러가 낮은 우선순위 인덱스에서 wheel을 시도하기 전에 높은 우선순위 인덱스에서 sdist를 사용해야 할까요?
  • 플랫폼 특정 wheel vs 덜 특정 wheel: 인스톨러가 낮은 우선순위 인덱스에서 더 특정적인 wheel을 사용하기 전에 높은 우선순위 인덱스에서 덜 특정적인 wheel을 사용해야 할까요?
  • pip의 --prefer-binary와 같은 플래그: 인스톨러가 낮은 우선순위 인덱스의 wheel을 고려하기 전에 높은 우선순위 인덱스에서 sdist를 사용해야 할까요?

인스톨러는 이러한 우선순위를 다양한 방식으로 구현할 수 있지만, 최적화 기준과 낮은 우선순위 인덱스로의 폴백 처리 방식을 문서화해야 합니다. 예를 들어, 인스톨러는 --prefer-binary가 구성된 모든 인덱스를 반복하고 설치 가능한 바이너리 후보를 찾지 못한 경우에만 sdist를 설치해야 한다고 명시할 수 있습니다.

미러링 (Mirroring)

지금까지 설명된 바와 같이, 인덱스 우선순위 체계는 동일한 콘텐츠를 제공하는 여러 인덱스 URL의 사용 사례를 저해합니다. 이러한 미러는 네트워크 문제를 완화하거나 신뢰성을 향상시키기 위해 사용될 수 있습니다. 인덱스 우선순위를 추가하면서 미러링 기능을 유지하기 위해 인스톨러가 취할 수 있는 한 가지 접근 방식은 사용자 정의 가능한 인덱스 그룹 개념을 추가하는 것입니다. 이 경우 그룹의 각 인덱스는 동등하다고 가정합니다. 이는 Poetry의 패키지 소스 개념과 관련이 있지만, 이는 임의의 수의 우선순위가 지정될 수 있는 그룹을 허용하고, 그룹 구성원은 미러라고 가정합니다. 각 그룹 내에서는 콘텐츠가 결합되거나 각 구성원이 동시에 페치될 수 있습니다. 가장 빠르게 응답하는 인덱스가 그룹을 대표하게 됩니다.

하위 호환성 (Backwards Compatibility)

이 PEP는 어떤 인스톨러에 대해서도 변경을 의무화하지 않으므로, 도구가 현재 구현하는 동작 외의 인덱스 동작을 채택하는 경우에만 호환성 문제를 야기합니다.

이 PEP의 용어는 pip 및 uv를 포함한 기존 도구들과 완전히 일치하지 않습니다. 이 PEP의 용어는 검토 과정에서 변경될 수도 있고, 이 PEP의 용어가 선호된다면 다른 프로젝트들이 이에 따를 수도 있습니다. 이러한 용어를 제안하는 유일한 목표는 사용자가 다른 인스톨러에 대해 쉽게 배울 수 있도록 하는 중앙의 공통 어휘를 만드는 것입니다.

일부 도구가 한 가지 또는 다른 동작에 의존하기 때문에, 특정 동작에 맞게 가용 자원/패키지를 조정하는 것이 다른 동작에 의존하는 사용자들의 경험을 저해할 수 있는 일부 문제가 발생할 수 있습니다.

  • 다른 인덱스는 다른 메타데이터를 가질 수 있습니다. 예를 들어, 인덱스 “A”의 패키지 “something”에 대한 메타데이터가 인덱스 “B”의 “something”과 동일한 종속성을 가진다고 가정할 수 없습니다. 이는 버전 우선순위의 근본적인 가정을 깨뜨리지만, 인덱스 우선순위는 이를 처리할 수 있습니다. 인스톨러가 검색 순서에서 낮은 우선순위 인덱스로 폴백할 때, 이는 새로운 인덱스에서 패키지 메타데이터를 새로 고침(refresh)하는 것을 의미합니다. 이는 개선이자 복잡성입니다. 캐시된 메타데이터 항목이 패키지 이름뿐만 아니라 인덱스 URL로도 키 지정되어야 한다는 점에서 복잡성입니다. 패키지의 다른 구현 변형이 배포본이 다른 인덱스로 분리되는 한 종속성이 다를 수 있다는 점에서 잠재적인 개선입니다.
  • 사용자는 인덱스 우선순위를 사용할 때 예상대로 업데이트를 받지 못할 수 있습니다. 이는 일부 높은 우선순위 인덱스가 최신 패키지를 얻기 위해 PyPI와 업데이트/동기화되지 않았기 때문입니다. 높은 우선순위 인덱스에 유효한 후보가 있으면, 더 새로운 패키지는 발견되지 않을 것입니다. 이는 pip의 잘 정립된 동작과 반대되기 때문에 자세히 전달해야 할 것입니다.
  • 인덱스 우선순위를 추가함으로써 인스톨러는 어떤 인덱스가 선택될지에 대한 예측 가능성을 향상시킬 것이며, 인덱스 호스트는 이를 사용하여 다른 내용을 가진 유사한 이름의 파일을 제공하는 방식으로 남용할 수 있습니다. 버전 우선순위의 경우, 이는 핵심 패키지 상호 교환성 가정을 위반하며, 혼란이 발생할 것입니다. 인덱스 우선순위는 더 실현 가능하지만, 상황은 여전히 큰 혼란을 야기할 가능성이 있습니다. 이러한 혼란스러운 문제를 식별하는 데 인스톨러를 지원하는 도구를 개발하는 것이 도움이 될 것입니다. 이러한 도구는 인스톨러 프로세스와 독립적으로 작동하여 인덱스 집합의 건전성(sanity)을 검증하는 수단이 될 수 있습니다. 이러한 도구의 시간 비용에 따라 인스톨러는 이를 프로세스의 일부로 실행할 수 있습니다. 물론 사용자들은 자신의 위험 부담으로 권장 사항을 무시할 수 있습니다.

보안 영향 (Security Implications)

인덱스 우선순위는 사용자가 자신의 인덱스 간에 신뢰 계층을 명시적으로 지정할 수 있는 메커니즘을 생성합니다. 따라서 종속성 혼란 공격의 잠재력을 제한합니다. 인덱스 우선순위는 PEP 708에서 종속성 혼란 공격에 대한 해결책으로 거부되었습니다. 이 PEP는 인덱스 우선순위가 다른 목적을 수행하면서 해당 거부가 재고될 것을 요청합니다. 이 PEP는 주로 구현 변형 지원에 대한 열망에 의해 동기 부여되며, 이는 PEP로 이어지기를 바라는 다른 논의의 주제입니다. PEP 708과 상호 배타적이지 않으며, PEP 708을 되돌리거나 철회할 것을 제안하지도 않습니다. 이는 사용자가 “설치당(per install)”보다 더 세분화된 수준에서 사용할 인덱스를 선택할 수 있도록 하는 방법에 대한 해답입니다.

PEP 708의 인덱스 우선순위 거부에 대한 더 자세한 논의는 이 PEP에 대한 discuss.python.org 스레드를 참조하십시오.

교육 방법 (How to Teach This)

처음부터 목표는 pip이나 다른 도구가 기본 우선순위 동작을 변경하도록 전환하는 것이 아닙니다. 아마도 가르치는 가장 좋은 방법은 메시지 게시판, GitHub 이슈 트래커 및 채팅 채널을 주시하며 인덱스 우선순위가 해결하는 데 도움이 될 수 있는 문제를 찾는 것입니다. 이 개념들을 알리기 좋은 몇 가지 오랜 논의들이 있습니다. 공식적으로 지원되는 두 가지 동작의 주제는 문서화가 필요하며, 이 PEP의 저자들은 이 PEP의 검토 기간 동안 이를 개발할 것입니다. 이 문서들은 여러 인덱스에 걸쳐 추가되고, 인스톨러 간의 개념을 상호 연결하는 방식으로 구성될 것입니다. 최소한 PyPUG 및 pip 문서에 추가할 것으로 예상됩니다.

인스톨러가 활성 동작을, 특히 오류 메시지에서, 광고하는 것이 중요하며, 이는 사용자에게 이러한 동작에 대한 리소스를 제공하는 방법을 제공할 것입니다.

uv 사용자들은 이미 인덱스 우선순위를 경험하고 있습니다. uv는 이 동작을 잘 문서화하고 있지만, 사용자가 실제로 예상치 못한 동작을 접하게 될 명령줄에서 해당 문서의 검색 가능성을 항상 개선할 수 있습니다.

참조 구현 (Reference Implementation)

uv 프로젝트는 기본 동작으로 인덱스 우선순위를 보여줍니다. uv는 Rust로 구현되었지만, Python 기반 도구에 대한 참조 구현이 필요한 경우, 이 PEP의 저자들이 제공할 것입니다. 특히 pip의 경우, 구현 계획은 다음과 같습니다.

  • --extra-index-url 또는 --find-links를 사용하지 않는 사용자의 경우, 변경 사항이 없으며 마이그레이션이 필요하지 않습니다.
  • pip 사용자는 CLI 및 pip.conf의 새로운 구성 설정으로 인덱스 우선순위 동작을 선택(opt-in)할 수 있을 것입니다. 이 제안은 어떤 전략도 어떤 인스톨러의 기본값으로 권장하지 않습니다. 단지 도구가 제공하는 전략을 문서화할 것을 권장할 뿐입니다.
  • 둘 이상의 인덱스가 사용되는 pip 작업에 대해 추가 정보 수준(info-level) 출력을 활성화합니다. 이 출력에는 현재 전략 설정, 함축된 동작에 대한 간결한 요약, 그리고 다양한 옵션을 설명하는 문서 링크를 포함합니다.
  • 파일이 구성 계층 구조에서 어디에 있는지, 그리고 어디에 포함되는지(구성 파일, 환경 변수 또는 CLI 플래그를 통해)를 포함하여 각 단계에서 사용되는 인덱스를 자세히 식별하는 디버깅 출력을 추가합니다.
  • 전체 pip install 프로세스를 통해 어떤 인덱스가 어떤 패키지/배포본에 사용되는지에 대한 추적을 연결합니다. pip freeze와 같은 도구에서 이 정보를 사용할 수 있도록 저장합니다.
  • PEP 751 (lockfiles)을 패키지/배포본이 나온 인덱스의 캡처로 보완합니다.

거부된 아이디어 (Rejected Ideas)

사용자에게 devpi 또는 Artifactory와 같은 프록시/미러를 설정하도록 안내 (Tell users to set up a proxy/mirror, such as devpi or Artifactory that serves local files if present, and forwards to another server (PyPI) if no local files match)

이 제안의 동작과 매우 유사하지만, 이 방법은 서버 호스팅을 필요로 하며 일부 환경에서는 사용자에게 접근 불가능하거나 구성할 수 없을 수 있습니다. 또한 자체 인덱스를 운영하는 조직(예: PyPI 크기 제한 극복용)의 경우, 이는 최종 사용자에게 --extra-index-url 또는 프록시/미러의 필요성을 해결하지 못한다는 점을 고려하는 것이 중요합니다. 즉, 조직은 PyPI 전체를 프록시/미러링하고 사용자가 자신의 프록시/미러를 유일한 인덱스로 구성하도록 하지 않는 한, 이 접근 방식으로부터 어떠한 개선도 얻지 못합니다.

빌드 태그 및/또는 로컬 버전 지정자로 충분한가? (Are build tags and/or local version specifiers enough?)

빌드 태그(build tags) 및 로컬 버전 지정자(local version specifiers)는 해당 태그 및/또는 로컬 버전 지정자가 없는 패키지보다 우선합니다. 패키지 풀에서, PyPI 이외의 서버에서 호스팅되는 이러한 추가 기능을 가진 빌드는 PyPI의 패키지보다 우선하며, PyPI는 빌드 태그를 거의 사용하지 않고 로컬 버전 지정자를 금지합니다. 이 접근 방식은 패키지 제공자가 자체 로컬 오버라이드(override)를 제공하기를 원할 때(예: 사용자에게 최적화된 빌드를 제공하는 HPC 관리자) 유용합니다. 빌드 태그가 pip freeze 메타데이터에 나타나지 않고, 로컬 버전 지정자가 PyPI에서 허용되지 않는다는 점에서 일부 방식으로는 덜 유용합니다. 또한 로컬 빌드 태그 변형을 가진 패키지 컬렉션을 구축하고 유지 관리하는 데 상당한 작업이 수반됩니다.

PEP 708은 어떤가? 그것으로 충분하지 않은가? (What about PEP 708? Isn’t that enough?)

PEP 708은 특히 종속성 혼란 공격을 다루는 것을 목표로 하며, 인덱스 간의 구현 변형 가능성을 다루지 않습니다. 이는 외부 URL을 필터링하고 인덱스 메타데이터에 외부 인덱스에 대한 허용 목록(allow-list)을 인코딩하는 방법입니다. 이는 현재 존재하는 채널 간의 우선순위 또는 선호도 부족을 변경하지 않습니다.

네임스페이싱 (Namespacing)

네임스페이싱은 패키지의 Python 사용은 변경되지 않지만, 패키지 설치가 패키지가 어디에서 오는지를 제한하는 방식으로 패키지를 지정하는 수단입니다. PEP 752는 최근 접두사를 그룹화 요소로 예약함으로써 평면적인 패키지 이름 공간(예: PyPI)에서 패키지 소유자를 다중화하는 방법을 제안했습니다. NPM의 “스코프(scopes)” 개념이 이것이 어떻게 보일 수 있는지에 대한 또 다른 좋은 예로 언급되었습니다. 이 PEP는 평면적인 패키지 이름 공간이 아닌 여러 인덱스를 대상으로 한다는 점에서 다릅니다. 예측 가능하게 특정 패키지 소스를 선택하는 측면에서는 순 효과가 대략 동일하지만, 네임스페이싱 접근 방식은 이러한 네임스페이스 접두사로 패키지를 명명하는 데 더 의존하는 반면, 이 PEP는 사용자가 지정하는 어떤 높은 우선순위 인덱스에서든 패키지를 가져오므로 덜 세분화됩니다. 네임스페이싱 접근 방식은 구성된 모든 인덱스가 주어진 네임스페이스를 유사하게 처리하는 데 의존하며, 이는 모든 구성된 인덱스가 동등하게 신뢰되지 않는다는 일반적인 우려를 남깁니다. 네임스페이스 아이디어는 이 PEP와 호환되지 않는 것은 아니지만, 이 PEP가 하는 방식만큼 인덱스의 신뢰 표현을 개선하지도 않습니다.

공개 문제 (Open Issues)

[여전히 결정/논의 중인 모든 사항]

감사 (Acknowledgements)

이 작업은 저자의 고용을 통해 NVIDIA로부터 재정적 지원을 받았습니다. NVIDIA 팀원들은 그들의 의견으로 이 PEP를 극적으로 개선했습니다. Astral Software는 인덱스 우선순위 동작을 개척하여 이 문서의 토대를 마련했습니다. pip 저자들은 일관된 지침과 버전 우선순위 동작에 대한 인내심 있는 소통에 대해, 특히 논쟁적인 보안 문제에 직면했을 때, 큰 찬사를 받아야 합니다.

이 문서는 퍼블릭 도메인 또는 CC0-1.0-Universal 라이선스 중 더 관대한 조건에 따라 배포됩니다.

⚠️ 알림: 이 문서는 AI를 활용하여 번역되었으며, 기술적 정확성을 보장하지 않습니다. 정확한 내용은 반드시 원문을 확인하시기 바랍니다.

Comments