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

Python 개선 제안 한국어 번역

PEP 766 – 여러 인덱스 간 명시적 우선순위 선택

Author:
Michael Sarahan <msarahan at gmail.com>
Sponsor:
Barry Warsaw <barry at python.org>
PEP-Delegate:
Paul Moore <p.f.moore at gmail.com>
Discussions-To:
Discourse thread
Status:
Draft
Type:
Informational
Topic:
Packaging
Created:
18-Nov-2024
Post-History:
18-Nov-2024
Table of Contents

번역·라이선스 안내

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

초록

패키지 해결은 Python의 핵심 기능을 확장하는 수단으로서 Python 사용자 경험의 핵심 부분입니다. 패키지 설치 프로그램이 예상하지 못한 작업을 수행하는 상황을 겪기 전까지는 패키지 해결 경험을 대부분 당연하게 여깁니다. 여러 인덱스를 사용할 때 설치 프로그램의 동작은 a common source of unexpected behavior이 흔히 예상하지 못한 동작의 원인이 되어 왔습니다. pip는 널리 사용되어 온 덕분에 생태계의 다른 도구 전반에서 기대되는 표준 동작을 오랫동안 정의해 왔지만, Python 설치 프로그램들은 여러 인덱스를 처리하는 방식에서 서로 다른 방향으로 나아가고 있습니다. 이러한 차이의 핵심은 배포 패키지를 해결하기 전에 인덱스의 내용을 결합하는지, 아니면 각 인덱스를 순서대로 개별 처리하는지에 있습니다. pip는 배포 패키지를 매칭하기 전에 모든 인덱스를 병합하는 반면, uv는 다음 인덱스로 넘어가기 전에 한 인덱스에서 배포 패키지를 매칭합니다. 각 접근 방식에는 장점과 단점이 있습니다. 이 PEP는 이러한 각 동작을 각각 “버전 우선순위”와 “인덱스 우선순위”라고 부르며 설명하고자 합니다. 이를 통해 커뮤니티의 논의와 문제 해결에서 공통된 용어를 사용하고, 도구가 이러한 설명을 바탕으로 예측 가능한 동작을 구현할 수 있도록 하는 것이 목적입니다.

동기

Python 패키지 사용자는 PyPI가 아닌 다른 인덱스나 패키지 소스를 지정해야 하는 경우를 자주 마주합니다. 외부 인덱스가 존재하는 데에는 여러 가지 이유가 있습니다.

이러한 경우 대부분 PyPI를 완전히 포기하는 것은 바람직하지 않습니다. 대신 사용자는 일반적으로 PyPI가 여전히 패키지 소스이기는 하되 우선순위가 더 낮은 소스이기를 원합니다. 안타깝게도 pip’s current design precludes this concept of priority입니다. 일부 Python 설치 도구는 인덱스 우선순위를 표현하는 메커니즘을 포함한 방식으로 여러 인덱스를 처리하는 대안을 개발했습니다. 예를 들어 uv 및 PDM이 있습니다.

혁신과 사용자 지정 가능성은 고무적이지만, 이미 Python의 약점 중 하나로 인식되는 Python 패키징 생태계를 더욱 분열시킬 위험도 따릅니다. 이 PEP의 동기는 설치 프로그램이 여러 인덱스를 처리하는 방식에 대해 더 많은 통찰을 제공하도록 장려하고, 더 넓은 커뮤니티에서 공통으로 사용할 수 있는 용어를 제공하는 데 있습니다.

사양

“버전 우선순위”

이 동작의 특징은 설치 프로그램이 패키지가 어느 인덱스에서 제공되는지와 관계없이 항상 패키지의 “최상의” 버전을 가져온다는 점입니다. “최상”은 패키지의 다양한 특성을 최적화하는 설치 프로그램의 알고리즘에 따라 정의되며, 사용자 입력(바이너리만 선호하거나 바이너리를 선호하지 않는 것 등)도 고려합니다. 설치 프로그램마다 최적화 기준과 사용자 옵션은 다를 수 있지만, 모든 버전 우선순위 설치 프로그램이 공유하는 일반적인 특징은 후보를 선택하기 전에 인덱스의 내용을 취합한다는 점입니다.

구성된 모든 인덱스가 배포판 상호 교환 가능성 가정과 관련하여 동일하게 신뢰할 수 있고 올바르게 작동할 때 버전 우선순위가 가장 유용합니다. 미러는 이 점에서 특히 올바르게 작동합니다. 이러한 상호 교환 가능성 가정이 있어야 특정 패키지의 배포판을 비교하는 것이 의미를 갖습니다. 이것이 없으면 설치 프로그램은 더 이상 “사과와 사과”를 비교하지 못합니다. 실제로 서로 다른 인덱스에 특수 하드웨어용 빌드나 동일한 패키지에 대한 서로 다른 메타데이터처럼 다른 인덱스의 파일과 내용이 다른 파일이 있는 경우가 흔합니다. 이러한 경우 버전 우선순위 동작은 바람직하지 않고 예상하지 못한 결과를 초래할 수 있으며, 이때 users generally look for some kind of index priority를 찾습니다. 또한 인덱스 간 신뢰도에 차이가 있을 때 버전 우선순위는 신뢰도가 낮은 인덱스보다 신뢰도가 높은 인덱스를 선호할 방법을 제공하지 않습니다. 이는 의존성 혼동 공격에 악용되었으며, PEP 708은 신뢰할 수 있는 외부 인덱스라는 개념을 인덱스에 하드코딩하는 방법으로 제안되었습니다.

“버전 우선순위”라는 이름은 새로 도입된 것이며, 새로운 용어의 도입은 항상 최소화해야 합니다. 이 PEP는 uv 프로젝트를 참고하며, uv 프로젝트는 its implementation of the version priority behavior를 “unsafe-best-match”라고 부릅니다. 여기서 이름을 정하는 일은 정말 어렵습니다. 한편 pip의 기본 동작을 본질적으로 “안전하지 않다”라고 부르는 것은 정확하지 않습니다. 악의적일 가능성이 있는 인덱스를 추가하는 것이 이 동작에 대한 우려를 불러일으킵니다. PEP 708은 설치 프로그램이 예상하지 못한, 잠재적으로 안전하지 않은 인덱스에서 패키지를 가져오지 못하도록 제한하는 방법을 추가했습니다. 다른 한편으로 “최적 일치”라는 용어는 기술적으로는 정확하지만 오해를 불러일으키기도 합니다. “최적 일치”는 사용자와 애플리케이션에 따라 달라집니다. “최적”은 위에서 지정한 일치 기준에 따른 전역 최적이라는 의미에서는 기술적으로 정확하지만, 사용자의 관점에서 반드시 “최적”인 것은 아닙니다. “버전 우선순위”는 uv의 용어가 불러일으키는 우려를 피하면서 패키지를 비교하는 동작을 사용자가 가장 쉽게 식별할 수 있는 방식으로 근사하는 제안된 용어입니다.

“인덱스 우선순위”

인덱스 우선순위에서는 확인자가 각 인덱스에 대한 후보를 한 번에 하나씩 찾습니다. 현재 패키지 요청에 실행 가능한 후보가 없는 경우에만 확인자가 다음 인덱스로 진행합니다. 인덱스 우선순위는 인덱스들을 하나의 전역 플랫 네임스페이스로 결합하지 않습니다. 인덱스는 순서대로 검색되므로, 나중 인덱스가 설치 프로그램의 최적화 기준에 더 잘 맞는 후보를 가지고 있었는지와 관계없이 앞선 인덱스의 패키지가 나중 인덱스의 패키지보다 우선됩니다. 특정 설치 프로그램에서 최적화 기준과 선택 알고리즘은 인덱스 우선순위와 버전 우선순위 모두에 대해 동일해야 합니다. 차이가 나는 것은 여러 인덱스를 처리하는 방식뿐입니다. 버전 우선순위에서는 모두 함께 처리하고, 인덱스 우선순위에서는 개별적으로 처리합니다.

인덱스 지정 순서가 찾기 과정에서 인덱스의 우선순위를 결정합니다. 그 결과 설치 프로그램이 인덱스 구성을 불러오는 방식은 예측 가능하고 재현 가능해야 합니다. 이 PEP는 특정 메커니즘을 규정하지 않으며, 설치 프로그램이 소스 모음의 순서를 정하는 방법을 제공해야 한다고만 명시합니다. 설치 프로그램은 어떤 인덱스를 고려 중인지 파악할 수 있도록 선택적 디버깅 출력을 제공하는 것이 이상적입니다.

각 패키지의 찾기 기능은 인덱스 목록의 처음부터 시작해야 하므로, 각 패키지는 인덱스 목록을 처음부터 다시 시작합니다. 다시 말해, 한 패키지에 첫 번째 인덱스에서 유효한 후보가 없지만 두 번째 인덱스에서 일치 항목을 찾았더라도, 이후 패키지는 두 번째 인덱스에서 시작하지 말고 여전히 첫 번째 인덱스에서 검색을 시작해야 합니다.

인덱스 우선순위 전략이 암시하는 바람직한 동작 중 하나는 “깜짝” 업데이트가 없다는 것입니다. 즉, 우선순위가 낮은 인덱스의 버전 증가가 선별되고 승인된 우선순위가 높은 인덱스를 이기는 일이 없어야 합니다. 이는 배포판이 가져올 수 있는 외부 인덱스를 패키지가 제한할 수 있도록 한 PEP 708의 보안 개선과 관련이 있지만, 인덱스 우선순위는 최종 사용자가 더 다양하게 구성할 수 있습니다. 패키지 설치는 우선순위가 높은 인덱스 또는 인덱스 우선순위 구성이 변경될 때만 변경될 것으로 예상됩니다. 이러한 안정성과 예측 가능성 덕분에 인덱스를 한 번의 설치 명령에 대한 일회성 인자가 아니라 환경의 더 지속적인 속성으로 구성하는 것이 더욱 실현 가능해집니다.

캐시 키

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

요청이 우선순위가 더 낮은 인덱스로 넘어가는 방식

  • 우선순위가 더 높은 인덱스에 패키지 이름이 전혀 없습니다.
  • 버전 지정자, 호환되는 Python 버전, 플랫폼 태그, 철회 또는 기타 사유로 우선순위가 더 높은 인덱스의 모든 배포 파일이 필터링됩니다.
  • 설치 관리자의 거부 목록 구성에서 특정 인덱스의 특정 패키지 이름을 무시하도록 지정합니다.
  • 우선순위가 더 높은 인덱스에 연결할 수 없습니다(예: 방화벽 규칙으로 차단되었거나, 유지 관리로 인해 일시적으로 사용할 수 없거나, 기타 여러 일시적인 네트워크 문제가 발생한 경우). 이는 사용자가 제어할 수 있어야 하는, 경계가 다소 모호한 세부 사항입니다. 한편, 이 동작은 예기치 않게 우선순위가 더 낮은 인덱스로 넘어가게 하므로 결과의 예측 가능성이 낮아지고, 재현이 어려워질 가능성이 있습니다. 다른 한편으로는 일부 사용자에게 정상적인 대체 처리가 더 중요할 수 있으며, 특히 모든 인덱스를 동등하게 신뢰할 수 있다고 안전하게 가정할 수 있는 경우에는 더욱 그렇습니다. 현재 pip의 동작은 정상적인 대체 처리입니다. 인덱스에 연결 문제가 있으면 경고가 표시되지만, 설치는 사용 가능한 다른 인덱스를 사용하여 계속 진행됩니다. 인덱스 우선순위는 인덱스 간의 서로 다른 신뢰 수준을 전달할 수 있으므로, 인덱스 우선순위를 구현하는 설치 관리자는 네트워크 문제 발생 시 기본적으로 오류를 발생시키고 중단해야 합니다. 설치 관리자는 네트워크 오류가 발생한 경우 우선순위가 더 낮은 인덱스로 넘어갈 수 있도록 하는 플래그를 제공할 수 있습니다.

특정 인덱스 내에서의 처리는 기존 동작을 따르지만, 하나의 인덱스 범위에서 멈추고 해당 인덱스 내의 모든 우선순위 선호 사항을 소진한 후에만 다음 인덱스로 이동합니다. 즉, 통합된 패키지 모음에서 기존에 적용되던 우선순위가 우선순위가 더 낮은 인덱스로 넘어가기 전에 각 인덱스에 개별적으로 적용됩니다.

최적화 기준의 모든 수준에서 절충해야 할 사항이 있습니다.

  • 버전: 다른 인덱스에서 더 최신 버전을 사용할 수 있더라도 인덱스 우선순위에 따라 우선순위가 더 높은 인덱스의 더 오래된 버전을 사용합니다.
  • wheel과 sdist: 설치 관리자는 우선순위가 더 낮은 인덱스의 wheel을 시도하기 전에 우선순위가 더 높은 인덱스의 sdist를 사용해야 합니까?
  • 플랫폼별로 더 구체적인 wheel보다 덜 구체적인 wheel을 먼저 고려: 설치 관리자는 우선순위가 더 낮은 인덱스의 더 구체적인 wheel을 사용하기 전에 우선순위가 더 높은 인덱스의 덜 구체적인 wheel을 사용해야 합니까?
  • pip의 --prefer-binary와 같은 플래그: 설치 관리자는 우선순위가 더 낮은 인덱스의 wheel을 고려하기 전에 우선순위가 더 높은 인덱스의 sdist를 사용해야 합니까?

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

미러링

지금까지 설명한 것처럼 인덱스 우선순위 체계는 둘 이상의 인덱스 URL이 동일한 콘텐츠를 제공하는 사용 사례를 저해합니다. 이러한 미러는 네트워크 문제를 완화하거나 그 밖의 방식으로 안정성을 향상하려는 목적으로 사용할 수 있습니다. 인덱스 우선순위를 추가하면서 미러링 기능을 유지하기 위해 설치 관리자가 취할 수 있는 한 가지 방법은 사용자가 정의할 수 있는 인덱스 그룹이라는 개념을 추가하는 것입니다. 이 그룹의 각 인덱스는 동등한 것으로 간주됩니다. 이는 Poetry’s notion of package sources의 개념과 관련되지만, 임의의 수의 우선순위 지정 가능 그룹을 허용하고 그룹 구성원이 미러라고 가정한다는 점이 다릅니다. 각 그룹 내에서 콘텐츠를 결합하거나 각 구성원에서 동시에 가져올 수 있습니다. 그러면 가장 빠르게 응답하는 인덱스가 해당 그룹을 대표합니다.

하위 호환성

이 PEP는 어떤 설치 관리자에도 변경 사항을 의무적으로 적용하도록 규정하지 않으므로, 도구가 현재 구현하는 동작과 다른 인덱스 동작을 채택하기로 선택하는 경우에만 호환성 문제가 발생합니다.

이 PEP의 표현은 pip 및 uv를 비롯한 기존 도구와 완전히 일치하지는 않습니다. 이 PEP를 검토하는 동안 이 PEP의 표현을 변경할 수도 있고, 이 PEP의 표현을 선호한다면 다른 프로젝트가 이에 맞출 수도 있습니다. 이러한 용어를 제안하는 유일한 목적은 사용자가 다른 설치 프로그램을 더 쉽게 배울 수 있도록 중앙의 공통 어휘를 만드는 것입니다.

일부 도구는 한쪽 동작이나 다른 쪽 동작에 의존하므로, 특정 동작에 맞춰 사용 가능한 리소스/패키지를 조정하면 다른 동작에 의존하는 사용자의 사용자 경험이 저하될 수 있는 몇 가지 문제가 발생할 수 있습니다.

  • 서로 다른 색인에는 서로 다른 메타데이터가 있을 수 있습니다. 예를 들어 색인 “A”의 패키지 “something”에 대한 메타데이터가 색인 “B”의 “something”과 동일한 의존성을 가진다고 가정할 수는 없습니다. 이는 버전 우선순위의 근본적인 가정을 깨뜨리지만, 색인 우선순위로 처리할 수 있습니다. 설치 프로그램이 검색 순서에서 우선순위가 더 낮은 색인으로 넘어가면 새 색인에서 패키지 메타데이터를 새로 고친다는 의미가 됩니다. 이는 개선인 동시에 복잡성을 증가시키는 요소입니다. 패키지 이름만으로 키를 지정하는 대신, 캐시된 메타데이터 항목의 키를 패키지 이름과 색인 URL 모두로 지정해야 한다는 점에서 복잡성이 증가합니다. 패키지의 서로 다른 구현 변형이 서로 다른 색인에 배포되어 있기만 하다면 의존성이 서로 다를 수 있다는 점에서 잠재적인 개선이 됩니다.
  • 더 높은 우선순위의 일부 색인이 최신 패키지를 얻기 위해 PyPI와 업데이트하거나 동기화되지 않았기 때문에, 색인 우선순위를 사용할 때 사용자가 예상한 대로 업데이트를 받지 못할 수 있습니다. 더 높은 우선순위의 색인에 유효한 후보가 있으면 더 최신인 패키지를 찾지 못합니다. 이는 pip의 확립된 동작과 반대되므로 매우 상세하게 전달해야 합니다.
  • 색인 우선순위를 추가하면 설치 프로그램이 선택될 색인을 더 예측 가능하게 만들며, 색인 호스트가 이를 악용하여 이름은 비슷하지만 내용은 다른 파일을 제공할 수 있습니다. 버전 우선순위를 사용하면 이는 핵심적인 패키지 상호 교환 가능성 가정을 위반하며, 큰 혼란이 초래됩니다. 색인 우선순위가 더 실용적이겠지만, 이 상황은 여전히 큰 혼란을 일으킬 가능성이 있습니다. 설치 프로그램이 이러한 혼란스러운 문제를 식별하도록 지원하는 도구를 개발하면 유용할 것입니다. 이러한 도구는 색인 집합의 타당성을 검증하는 수단으로 설치 프로그램 프로세스와 독립적으로 작동할 수 있습니다. 이러한 도구의 실행 시간 비용에 따라 설치 프로그램이 해당 도구를 자체 프로세스의 일부로 실행할 수도 있습니다. 물론 사용자는 자신의 책임하에 권고 사항을 무시할 수 있습니다.

보안 관련 사항

색인 우선순위는 사용자가 색인 간의 신뢰 계층을 명시적으로 지정할 수 있는 메커니즘을 만듭니다. 따라서 의존성 혼동 공격의 가능성을 제한합니다. 색인 우선순위는 의존성 혼동 공격에 대한 해결책으로 PEP 708에서 거부되었습니다. 이 PEP는 색인 우선순위가 다른 목적에 사용된다는 점을 전제로 해당 거부를 재고해 달라고 요청합니다. 이 PEP는 주로 구현 변형을 지원하려는 바람에서 비롯되었으며, 이는 another discussion that hopefully leads to a PEP의 주제입니다. 이는 PEP 708과 상호 배타적이지 않으며, PEP 708을 되돌리거나 철회하자는 제안도 아닙니다. 이는 사용자가 “per install”보다 더 세분화된 수준에서 사용할 색인을 선택할 수 있도록 하는 방법에 대한 답변입니다: how we could allow users to choose which index to use at a more fine grained level than “per install”.

색인 우선순위에 대한 PEP 708의 거부를 더 자세히 논의하려면 이 PEP에 관한 discuss.python.org thread for this PEP를 참조하십시오.

이 내용을 가르치는 방법

처음부터 목표는 pip 또는 다른 도구를 변환하여 기본 우선순위 동작을 변경하도록 하는 것이 아닙니다. 개념을 알리는 가장 좋은 방법은 아마 게시판, GitHub 이슈 추적기 및 채팅 채널을 살펴보면서 패키지 색인 우선순위로 해결하는 데 도움이 될 수 있는 문제를 주시하는 것입니다. 여러개의 오래 지속된 논의와 해당 될 곳이 개념을 알리기 시작하기에 좋습니다. 공식적으로 지원되는 두 동작에 관한 주제에는 문서가 필요하며, 이 PEP의 작성자인 저희는 이 PEP의 검토 기간에 이를 개발할 것입니다. 이러한 문서는 여러 색인에 걸친 추가 내용으로 구성되고, 설치 관리자 간에 개념을 상호 연결할 가능성이 높습니다. 최소한 PyPUG와 pip의 문서에 내용을 추가할 예정입니다.

설치 관리자가 활성 동작을 알리는 것이 중요하며, 특히 오류 메시지에서 이를 알리는 것이 중요합니다. 그러면 사용자에게 이러한 동작에 관한 자료를 제공할 방법이 마련됩니다.

uv 사용자는 이미 패키지 색인 우선순위를 경험하고 있습니다. uv는 이 동작을 잘 문서화하고 있지만, 사용자가 실제로 예상하지 못한 동작을 접하게 될 명령줄에서 해당 문서의 검색 가능성을 개선할여지는 언제나 있으며, 그 지점에서 사용자는 실제로 예상하지 못한 동작을 접하게 됩니다.

참조 구현

uv 프로젝트는 기본 동작으로 패키지 색인 우선순위를 보여 줍니다. 그러나 uv는 Rust로 구현되어 있으므로 Python 기반 도구의 참조 구현이 필요하다면 이 PEP의 작성자인 저희가 하나 제공할 것입니다. 특히 pip의 경우 구현 계획은 다음과 비슷할 것으로 봅니다.

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

거부된 아이디어

  • devpi또는 Artifactory와 같은 프록시/미러를 설정하도록 사용자에게 안내하십시오. 이러한 프록시/미러는 로컬 파일이 있으면 이를 제공하고, 일치하는 로컬 파일이 없으면 다른 서버(PyPI)로 전달합니다.

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

  • 빌드 태그 및/또는 로컬 버전 지정자면 충분합니까?

    빌드 태그와 로컬 버전 지정자는 이러한 태그 및/또는 로컬 버전 지정자가 없는 패키지보다 우선합니다. 패키지 풀에서 이러한 추가 요소가 포함된 빌드가 PyPI가 아닌 다른 서버에서 호스팅되면, 빌드 태그를 거의 사용하지 않고 로컬 버전 지정자를 금지하는 PyPI의 패키지보다 우선합니다. 이 접근 방식은 패키지 제공자가 자체적인 로컬 재정의를 제공하려는 경우, 예를 들어 사용자에게 최적화된 빌드를 제공하는 HPC 유지 관리자와 같은 경우에 실행 가능합니다. 그러나 빌드 태그가 pip freeze메타데이터에 표시되지 않고, 로컬 버전 지정자가 PyPI에서 허용되지 않는다는 점과 같은 이유로 일부 측면에서는 실행 가능성이 낮습니다. 로컬 빌드 태그 변형을 포함한 패키지 컬렉션을 구축하고 유지 관리하는 데에도 상당한 작업이 필요합니다.

    https://discuss.python.org/t/dependency-notation-including-the-index-url/5659/21

  • 그렇다면 PEP 708은 어떻습니까? 그것으로 충분하지 않습니까?

    PEP 708은 의존성 혼동 공격을 해결하는 데 중점을 두며, 인덱스 간 구현 변형 가능성은 다루지 않습니다. 이는 외부 URL을 필터링하고 인덱스 메타데이터에 외부 인덱스에 대한 허용 목록을 인코딩하는 방법입니다. 이는 현재 존재하는 채널 간 우선순위 또는 선호도의 부재를 변경하지 않습니다.

  • Namespacing

    네임스페이스화는 패키지의 Python 사용 방식은 변경하지 않으면서 패키지 설치 시 패키지의 출처를 제한하도록 패키지를 지정하는 방법입니다. PEP 752는 최근 접두사를 그룹화 요소로 예약하여 평면 패키지 네임스페이스(예: PyPI)에서 패키지 소유자를 다중화하는 방법을 제안했습니다. NPM’s concept of “scopes”는 이것이 어떤 형태일 수 있는지를 보여 주는 또 다른 좋은 예로 제시되었습니다. 이 PEP는 평면 패키지 네임스페이스가 아니라 여러 인덱스를 대상으로 한다는 점에서 다릅니다. 특정 패키지 소스를 예측 가능하게 선택한다는 측면에서 순효과는 대체로 동일하지만, 네임스페이스화 방식은 이러한 네임스페이스 접두사를 사용하여 패키지 이름을 지정하는 데 더 의존하는 반면, 이 PEP는 더 세분화되지 않아 사용자가 지정한 더 높은 우선순위의 인덱스에서 패키지를 가져옵니다. 네임스페이스화 방식은 구성된 모든 인덱스가 주어진 네임스페이스를 유사하게 처리한다고 전제하므로, 구성된 인덱스가 모두 동일하게 신뢰할 수 있는 것은 아니라는 일반적인 우려가 남습니다. 네임스페이스라는 발상은 이 PEP와 양립할 수 있지만, 이 PEP가 하는 방식으로 인덱스에 대한 신뢰를 표현하는 것을 개선하지는 않습니다.

공개 쟁점

[아직 결정 또는 논의 중인 모든 사항입니다.]

감사의 글

이 작업은 저자의 고용을 통한 NVIDIA의 재정적 지원을 받았습니다. NVIDIA 팀원들은 의견을 제공하여 이 PEP를 크게 개선했습니다. Astral Software는 인덱스 우선순위 동작을 개척했으며, 이에 따라 이 문서의 토대를 마련했습니다. pip 저자들은 일관된 방향성과 버전 우선순위 동작을 인내심 있게 설명한 점에서 큰 찬사를 받을 만하며, 특히 논쟁적인 보안 우려에 직면한 상황에서는 더욱 그렇습니다.