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

번역·라이선스 안내

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

초록

패키지 해석은 Python의 핵심 기능을 확장하는 수단으로서 Python 사용자 경험의 핵심적인 부분입니다. 패키지 해석 경험은 대부분 당연하게 여겨지다가, 누군가 패키지 설치 프로그램이 예상하지 못한 동작을 하는 상황을 마주하고 나서야 주목받습니다. 여러 색인을 다룰 때 설치 프로그램이 보이는 동작은 예상치 못한 동작의 흔한 원인이었습니다. pip은 어디에서나 쓰인다는 점 때문에 오랫동안 생태계의 다른 도구들 사이에서 표준적인 기대 동작을 정의해 왔지만, Python 설치 프로그램들은 여러 색인을 처리하는 방식에서 서로 갈라지고 있습니다. 이러한 차이의 핵심은 배포 패키지를 해석하기 전에 인덱스 내용을 합치는지, 아니면 각 인덱스를 순서대로 하나씩 처리하는지에 있습니다. pip는 배포 패키지를 매칭하기 전에 모든 인덱스를 병합하는 반면, uv는 한 인덱스에서 배포 패키지를 매칭한 뒤에 다음 인덱스로 넘어갑니다. 각 접근 방식에는 장점과 단점이 있습니다. 이 PEP는 각각 “버전 우선순위”와 “인덱스 우선순위”라고 부르는 이 동작들을 기술하여, 커뮤니티의 논의와 문제 해결에서 공통된 용어를 사용할 수 있게 하고, 도구들이 이 기술을 바탕으로 예측 가능한 동작을 구현할 수 있게 하는 것을 목표로 합니다.

동기

Python 패키지 사용자는 PyPI가 아닌 다른 인덱스나 패키지 소스를 지정해야 하는 상황에 자주 놓입니다. 외부 인덱스가 존재하는 이유는 다양합니다.

• PyPI의 파일 크기/할당량 제한
• PyTorch의 서로 다른 GPU 라이브러리 빌드와 같은 구현 변형
• 조직 내부에서 공유하는 패키지의 로컬 빌드
• 로컬 패키지에 원격 의존성이 있는 상황에서, 사용자가 원격 의존성보다 로컬 패키지를 우선하되 필요한 경우에는 여전히 원격 의존성으로 대체하기를 원하는 경우

이러한 경우 대부분에서 PyPI를 완전히 포기하는 것은 바람직하지 않습니다. 사용자들은 대개 PyPI를 여전히 패키지 소스로 쓰되, 우선순위가 더 낮은 소스로 두기를 원합니다. 안타깝게도 pip의 현재 설계에서는 이러한 우선순위 개념을 적용할 수 없습니다. 일부 Python 설치 프로그램 도구는 여러 색인을 처리하는 대안적인 방식을 개발했으며, 여기에는 uv와 PDM처럼 색인 우선순위를 표현하는 메커니즘이 포함되어 있습니다.

이러한 혁신과 사용자 정의 가능성은 반가운 일이지만, 이미 Python의 약점 중 하나로 여겨지는 Python 패키징 생태계를 더욱 파편화할 위험이 따릅니다. 이 PEP의 동기는 설치 프로그램이 여러 색인을 어떻게 처리하는지 더 잘 드러내도록 장려하고, 더 넓은 커뮤니티가 공통으로 사용할 수 있는 용어를 제공하는 것입니다.

명세

“버전 우선순위”

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

버전 우선순위는 설정된 모든 인덱스를 똑같이 신뢰할 수 있고, 모든 인덱스가 배포물 상호 교환 가능성 가정을 잘 지킬 때 가장 유용합니다. 미러는 이 점에서 특히 잘 동작합니다. 주어진 패키지의 배포물끼리 비교하는 것이 의미를 갖는 것은 바로 이 상호 교환 가능성 가정 덕분입니다. 이 가정이 없으면 설치 프로그램은 더 이상 “같은 것끼리” 비교하지 않게 됩니다. 실제로는 특수 하드웨어용 빌드나 같은 패키지에 대한 서로 다른 메타데이터처럼, 색인마다 다른 색인과 내용이 다른 파일을 가지고 있는 경우가 흔합니다. 이런 경우 버전 우선순위 동작은 바람직하지 않고 예상치 못한 결과로 이어질 수 있으며, 바로 이 지점에서 사용자들은 대개 어떤 형태의 인덱스 우선순위를 찾게 됩니다. 또한 인덱스 간 신뢰도에 차이가 있을 때, 버전 우선순위는 신뢰도가 낮은 인덱스보다 신뢰도가 높은 인덱스를 우선할 방법을 제공하지 않습니다. 이 점은 의존성 혼동 공격에 악용되어 왔으며, PEP 708은 신뢰할 수 있는 외부 인덱스라는 개념을 인덱스에 하드코딩하는 방법으로 제안되었습니다.

“버전 우선순위”라는 이름은 새로운 것이며, 새로운 용어의 도입은 언제나 최소화해야 합니다. 이 PEP는 uv 프로젝트를 참고합니다. uv 프로젝트는 버전 우선순위 동작에 대한 자체 구현을 “unsafe-best-match”라고 부릅니다. 여기서는 이름을 정하기가 정말 어렵습니다. 한편으로는 pip의 기본 동작을 본질적으로 “안전하지 않다”고 부르는 것은 정확하지 않습니다. 이 동작에 우려를 낳는 것은 악의적일 수 있는 색인의 추가입니다. PEP 708은 설치 프로그램이 예상치 못한, 잠재적으로 안전하지 않은 색인에서 패키지를 가져오지 못하도록 제한하는 방법을 추가했습니다. 다른 한편으로, “최적 일치(best-match)”라는 용어는 기술적으로는 정확하지만 오해의 소지도 있습니다. “최적 일치”는 사용자와 애플리케이션에 따라 달라집니다. “최적”은 앞서 명시한 일치 기준에 따른 전역 최적값이라는 의미에서 기술적으로는 정확하지만, 그것이 반드시 사용자가 보기에 “최적”인 것은 아닙니다. “버전 우선순위”는 uv 용어의 이러한 문제를 피하면서도, 패키지를 비교하는 방식을 사용자가 가장 쉽게 알아볼 수 있는 형태로 그 동작을 근사적으로 표현하기 위해 제안된 용어입니다.

“인덱스 우선순위”

인덱스 우선순위에서 리졸버는 한 번에 하나씩 각 인덱스에서 후보를 찾습니다. 리졸버는 현재 패키지 요청에 적합한 후보가 없을 때에만 다음 인덱스로 넘어갑니다. 인덱스 우선순위는 인덱스들을 하나의 전역적이고 평평한 네임스페이스로 합치지 않습니다. 색인은 순서대로 검색되므로, 뒤쪽 색인이 설치 프로그램의 최적화 기준에 더 잘 맞는 패키지를 가지고 있는지와 관계없이 앞쪽 색인의 패키지가 뒤쪽 색인의 패키지보다 우선합니다. 어떤 설치 프로그램에서든 최적화 기준과 선택 알고리즘은 색인 우선순위와 버전 우선순위에서 동일해야 합니다. 다른 것은 여러 인덱스를 다루는 방식뿐입니다. 버전 우선순위에서는 모든 인덱스를 한꺼번에 다루고, 인덱스 우선순위에서는 각 인덱스를 개별적으로 다룹니다.

인덱스를 명세하는 순서에 따라 탐색 과정에서 각 인덱스의 우선순위가 결정됩니다. 따라서 설치 프로그램이 색인 설정을 불러오는 방식은 예측 가능하고 재현 가능해야 합니다. 이 PEP는 설치 프로그램이 소스 모음의 순서를 정하는 방법을 제공해야 한다는 것 외에는 특정 메커니즘을 규정하지 않습니다. 또한 설치 프로그램은 어떤 색인이 고려되고 있는지 알 수 있게 해 주는 선택적 디버깅 출력을 제공하는 것이 이상적입니다.

각 패키지의 파인더는 인덱스 목록의 처음부터 시작해야 합니다. 즉, 각 패키지는 인덱스 목록을 처음부터 다시 탐색합니다. 다시 말해, 어떤 패키지가 첫 번째 인덱스에서 유효한 후보를 찾지 못하고 두 번째 인덱스에서 찾았더라도, 이후 패키지들은 두 번째 인덱스가 아니라 여전히 첫 번째 인덱스부터 탐색을 시작해야 합니다.

인덱스 우선순위 전략이 함축하는 바람직한 동작 중 하나는 우선순위가 낮은 인덱스에서 버전이 올라가 선별 및 승인을 거친 우선순위가 높은 인덱스를 이기는 “뜻밖의” 업데이트가 없다는 점입니다. 이는 패키지가 배포물을 가져올 수 있는 외부 인덱스를 제한할 수 있게 한 PEP 708의 보안 개선과 관련이 있지만, 인덱스 우선순위는 최종 사용자가 더 폭넓게 설정할 수 있습니다. 설치되는 패키지는 우선순위가 높은 인덱스나 인덱스 우선순위 설정이 바뀔 때에만 바뀔 것으로 예상됩니다. 이러한 안정성과 예측 가능성 덕분에 인덱스를 설치 명령 하나에만 쓰는 일회성 인자가 아니라 환경의 더 지속적인 속성으로 설정하는 것이 더 현실적인 선택이 됩니다.

캐시 키

인덱스 우선순위는 인덱스마다 특정 패키지에 대해 서로 다른 내용을 가질 수 있다는 가능성을 인정하는 것이므로, 이제 캐시와 잠금 파일(lockfile)에는 배포본을 내려받은 인덱스도 함께 기록해야 합니다. 이를 반영하지 않으면, 설정된 인덱스 목록을 변경한 뒤에 캐시나 잠금 파일이 우선순위가 더 낮은 인덱스에 있는, 이름이 비슷한 배포본을 제공할 수 있습니다. 모든 인덱스가 같은 파일 이름에 대해 인덱스 간에 동일한 파일을 제공하라는 권장 동작을 따른다면 이는 문제가 되지 않습니다. 그러나 그 권장 사항은 쉽게 강제할 수 없으므로, 캐시 키에 출처 인덱스를 추가하는 것이 현명한 방어적 변경입니다.

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

• 우선순위가 더 높은 인덱스에 해당 패키지 이름이 아예 없는 경우
• 우선순위가 더 높은 인덱스의 모든 배포본이 버전 지정자, 호환 Python 버전, 플랫폼 태그, 철회(yanking) 등의 이유로 걸러진 경우
• 설치 프로그램의 거부 목록 설정이 특정 패키지 이름을 주어진 색인에서 무시해야 한다고 지정하는 경우
• 우선순위가 더 높은 인덱스에 접근할 수 없는 경우(예: 방화벽 규칙으로 차단된 경우, 유지 보수로 일시적으로 사용할 수 없는 경우, 그 밖의 여러 일시적인 네트워크 문제가 있는 경우). 이는 명확하게 구분하기가 비교적 어려운 세부 사항이므로 사용자가 제어할 수 있어야 합니다. 한편으로 이 동작은 예기치 않게 우선순위가 더 낮은 인덱스로 넘어가게 하여 결과를 예측하기 어렵게 만들고, 재현할 수 없는 결과로 이어질 가능성이 높습니다. 다른 한편으로, 일부 사용자에게는 원활한 대체(graceful fallback)가 더 가치 있을 수 있습니다. 특히 모든 인덱스를 똑같이 신뢰할 수 있다고 안전하게 가정할 수 있는 경우에 그렇습니다. 현재 pip의 동작은 원활한 대체 방식입니다. 인덱스에 연결 문제가 있으면 경고가 표시되지만, 설치는 사용 가능한 다른 인덱스로 계속 진행됩니다. 색인 우선순위는 색인 간에 서로 다른 신뢰 수준을 나타낼 수 있으므로, 색인 우선순위를 구현하는 설치 프로그램은 네트워크 문제가 발생하면 기본적으로 오류를 발생시키고 중단해야 합니다. 설치 프로그램은 네트워크 오류가 발생했을 때 더 낮은 우선순위의 색인으로 넘어갈 수 있도록 허용하는 플래그를 제공할 수 있습니다.

한 인덱스 안에서의 처리는 기존 동작을 따르되, 그 인덱스의 범위에서 멈추며, 해당 인덱스 안의 모든 우선순위 선호 조건을 다 소진한 뒤에야 다음 인덱스로 넘어갑니다. 즉, 통합된 패키지 모음에 적용되던 기존 우선순위가 우선순위가 더 낮은 인덱스로 넘어가기 전에 각 인덱스에 개별적으로 적용됩니다.

최적화 기준의 모든 단계에서 절충해야 할 점이 있습니다.

• 버전: 인덱스 우선순위를 적용하면 다른 인덱스에 더 새로운 버전이 있더라도 우선순위가 더 높은 인덱스의 더 오래된 버전을 사용합니다.
• wheel 대 sdist: 설치 프로그램은 더 낮은 우선순위 색인의 wheel을 시도하기 전에 더 높은 우선순위 색인의 sdist를 사용해야 합니까?
• 덜 구체적인 wheel보다 플랫폼에 더 구체적인 wheel을 먼저 사용: 설치 프로그램은 더 낮은 우선순위 색인의 더 구체적인 wheel을 사용하기 전에 더 높은 우선순위 색인의 덜 구체적인 wheel을 사용해야 합니까?
• pip의 --prefer-binary 같은 플래그: 설치 프로그램은 더 낮은 우선순위 색인의 wheel을 고려하기 전에 더 높은 우선순위 색인의 sdist를 사용해야 합니까?

설치 프로그램은 이러한 우선순위를 각자 다른 방식으로 자유롭게 구현할 수 있지만, 자신의 최적화 기준과 더 낮은 우선순위 색인으로 넘어가는 방식을 문서화해야 합니다. 예를 들어, 설치 프로그램은 --prefer-binary가 설정된 모든 색인을 순회하고도 설치 가능한 바이너리 후보를 찾지 못한 경우가 아니면 sdist를 설치하지 않아야 한다고 정할 수 있습니다.

미러링

지금까지 설명한 인덱스 우선순위 방식을 적용하면 둘 이상의 인덱스 URL이 같은 내용을 제공하는 사용 사례가 동작하지 않게 됩니다. 이러한 미러는 네트워크 문제를 완화하거나 그 밖의 방식으로 안정성을 높이려는 목적으로 사용될 수 있습니다. 설치 프로그램이 색인 우선순위를 추가하면서도 미러링 기능을 유지하기 위해 취할 수 있는 한 가지 접근 방식은 사용자가 정의할 수 있는 색인 그룹 개념을 추가하는 것으로, 이때 그룹 안의 각 색인은 동등한 것으로 간주됩니다. 이는 Poetry의 패키지 소스 개념과 관련이 있지만, 우선순위를 지정할 수 있는 그룹을 임의의 개수만큼 둘 수 있다는 점과 한 그룹의 구성원을 미러로 간주한다는 점이 다릅니다. 각 그룹 안에서는 내용을 합칠 수도 있고, 각 구성원에서 동시에 가져올 수도 있습니다. 그러면 가장 빨리 응답하는 인덱스가 그 그룹을 대표하게 됩니다.

하위 호환성

이 PEP는 어떤 설치 프로그램에도 변경을 의무로 규정하지 않으므로, 도구가 현재 구현하고 있는 동작 이외의 색인 동작을 채택하기로 하는 경우에만 호환성 문제를 일으킵니다.

이 PEP의 용어는 pip와 uv를 비롯한 기존 도구의 용어와 완전히 일치하지는 않습니다. 이 PEP를 검토하는 과정에서 이 PEP의 용어를 바꿀 수도 있고, 이 PEP의 용어가 더 낫다고 판단되면 다른 프로젝트가 이를 따를 수도 있습니다. 이러한 용어를 제안하는 유일한 목적은 사용자가 다른 설치 프로그램에 대해 더 쉽게 배울 수 있도록 중심이 되는 공통 용어를 만드는 것입니다.

일부 도구는 두 동작 중 어느 한쪽에 의존하므로 몇 가지 문제가 생길 수 있습니다. 제공되는 리소스나 패키지를 특정 동작에 맞추면 다른 동작에 의존하는 사람들의 사용자 경험이 나빠질 수 있습니다.

• 색인마다 메타데이터가 다를 수 있습니다. 예를 들어, 색인 “A”에 있는 패키지 “something”의 메타데이터가 색인 “B”에 있는 “something”과 같은 의존성을 가진다고 가정할 수 없습니다. 이는 버전 우선순위의 근본 가정을 깨뜨리지만, 색인 우선순위는 이를 처리할 수 있습니다. 설치 프로그램이 검색 순서상 더 낮은 우선순위의 색인으로 넘어갈 때는 새 색인에서 패키지 메타데이터를 새로 가져와야 합니다. 이는 개선점인 동시에 복잡성을 더하는 요소입니다. 캐시된 메타데이터 항목의 키를 패키지 이름만으로 삼지 않고 패키지 이름과 색인 URL을 함께 써서 만들어야 한다는 점에서 복잡성이 늘어납니다. 패키지의 배포물이 서로 다른 색인으로 나뉘어 있기만 하면 그 패키지의 서로 다른 구현 변형이 서로 다른 의존성을 가질 수 있다는 점에서는 개선이 될 수 있습니다.
• 우선순위가 더 높은 어떤 색인이 PyPI와 갱신/동기화되지 않아 최신 패키지를 받아 두지 못했다면, 색인 우선순위를 사용하는 사용자는 기대한 대로 업데이트를 받지 못할 수 있습니다. 우선순위가 더 높은 색인에 유효한 후보가 있으면 더 새로운 패키지를 찾지 못합니다. 이는 오랫동안 자리 잡은 pip의 동작과 반대되므로 자세히 알려야 합니다.
• 색인 우선순위를 추가하면 설치 프로그램은 어떤 색인이 선택될지에 대한 예측 가능성을 높이게 되며, 색인 호스트는 이를 악용하여 이름은 비슷하지만 내용이 다른 파일을 둘 수도 있습니다. 버전 우선순위에서는 이것이 패키지를 서로 바꿔 쓸 수 있다는 핵심 가정을 위반하므로 큰 혼란이 벌어질 것입니다. 색인 우선순위라면 더 다룰 만하겠지만, 이 상황은 여전히 큰 혼란을 일으킬 가능성이 있습니다. 설치 프로그램이 이렇게 혼란스러운 문제를 식별하도록 돕는 도구를 개발하면 유용할 것입니다. 이러한 도구는 색인 집합이 정상적인지 검증하는 수단으로서 설치 프로그램 프로세스와 독립적으로 동작할 수 있습니다. 이러한 도구의 시간 비용에 따라 설치 프로그램은 이를 자신의 프로세스의 일부로 실행할 수 있습니다. 물론 사용자는 위험을 스스로 감수하고 권고를 무시할 수도 있습니다.

보안 영향

색인 우선순위는 사용자가 자신이 쓰는 색인 사이의 신뢰 계층을 명시적으로 지정할 수 있는 메커니즘을 제공합니다. 따라서 의존성 혼동 공격의 가능성을 줄입니다. 색인 우선순위는 의존성 혼동 공격에 대한 해결책으로서 PEP 708에서 기각되었습니다. 이 PEP는 색인 우선순위를 다른 목적으로 쓴다는 점을 고려하여 그 기각을 재고해 줄 것을 요청합니다. 이 PEP의 주된 동기는 구현 변형을 지원하려는 것이며, 이는 PEP로 이어지기를 바라는 또 다른 논의의 주제입니다. 이 PEP는 PEP 708과 상호 배타적이지 않으며, PEP 708을 되돌리거나 철회하자고 제안하지도 않습니다. 이 PEP는 사용자가 “설치 단위”보다 더 세밀한 수준에서 사용할 색인을 고를 수 있게 하는 방법에 대한 답입니다.

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

교육 방법

애초에 목표는 pip이나 다른 어떤 도구가 기본 우선순위 동작을 바꾸도록 만드는 것이 아닙니다. 가장 좋은 교육 방법은 아마도 메시지 게시판, GitHub 이슈 트래커, 채팅 채널을 지켜보면서 인덱스 우선순위로 해결할 수 있는 문제를 눈여겨보는 것입니다. 이 개념을 알리기 시작하기에 좋은 출발점이 될 여러 오래된 논의가 있습니다. 공식적으로 지원되는 두 가지 동작에 관한 주제는 문서화가 필요하며, 이 PEP의 저자인 저희가 이 PEP의 검토 기간 동안 이 문서를 작성할 것입니다. 이 문서는 여러 색인에 걸친 추가 내용으로 구성되어, 설치 프로그램 간의 개념을 상호 연결할 것입니다. 최소한 PyPUG와 pip 문서에 내용을 추가할 것으로 예상합니다.

설치 프로그램이 현재 적용 중인 동작을 특히 오류 메시지에서 알리는 것이 중요할 것이며, 이를 통해 이러한 동작에 관한 자료를 사용자에게 제공할 방법이 마련될 것입니다.

uv 사용자는 이미 인덱스 우선순위를 경험하고 있습니다. uv는 이 동작을 잘 문서화하고 있지만, 사용자가 실제로 예상치 못한 동작을 마주하게 되는 명령줄에서 그 문서를 더 쉽게 찾을 수 있도록 개선할 여지는 언제나 있습니다.

참조 구현

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

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

기각된 아이디어

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

  이 방법은 이 제안의 동작과 매우 가깝지만, 별도의 서버를 호스팅해야 하며 일부 환경에서는 사용자가 접근할 수 없거나 설정할 수 없을 수도 있다는 점이 다릅니다. 또한 (예를 들어 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은 의존성 혼동(dependency confusion) 공격을 해결하는 데 특화되어 있으며, 인덱스마다 구현이 다를 수 있는 가능성은 다루지 않습니다. 이는 외부 URL을 필터링하고, 외부 인덱스에 대한 허용 목록을 인덱스 메타데이터에 인코딩하는 방법입니다. 이는 현재 채널 간에 우선순위나 선호도가 없는 상황을 바꾸지 않습니다.

• 네임스페이스 지정

  네임스페이스 지정은 Python에서 패키지를 사용하는 방식은 바꾸지 않으면서, 패키지를 설치할 때 패키지를 가져오는 출처를 제한하도록 패키지를 지정하는 수단입니다. PEP 752는 최근 접두사를 그룹화 요소로 예약하여 평면적인 패키지 네임스페이스(예: PyPI)에서 패키지 소유자를 다중화하는 방법을 제안했습니다. NPM의 “스코프” 개념도 이것이 어떤 모습일 수 있는지 보여 주는 또 다른 좋은 예로 제기되었습니다. 이 PEP는 평면적인 패키지 네임스페이스가 아니라 여러 인덱스를 대상으로 한다는 점에서 다릅니다. 특정 패키지 출처를 예측 가능하게 선택한다는 측면에서 최종 효과는 대체로 같지만, 네임스페이스 지정 방식은 이러한 네임스페이스 접두사로 패키지 이름을 짓는 데 더 의존하는 반면, 이 PEP는 덜 세분화되어 있어서 사용자가 지정한 더 높은 우선순위의 인덱스라면 어디에서든 패키지를 가져옵니다. 네임스페이스 지정 방식은 구성된 모든 인덱스가 주어진 네임스페이스를 비슷하게 취급한다는 데 의존하므로, 구성된 모든 인덱스를 똑같이 신뢰할 수는 없다는 일반적인 우려가 남습니다. 네임스페이스라는 아이디어가 이 PEP와 양립할 수 없는 것은 아니지만, 이 PEP처럼 인덱스에 대한 신뢰를 표현하는 방식을 개선하지도 않습니다.

미해결 문제

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

감사의 글

이 작업은 NVIDIA가 저자를 고용하는 형태로 재정적 지원을 받았습니다. NVIDIA 동료들의 의견 덕분에 이 PEP가 크게 개선되었습니다. Astral Software는 인덱스 우선순위 동작을 선도적으로 도입하여 이 문서의 토대를 마련했습니다. pip 저자들은 특히 논쟁적인 보안 우려 속에서도 버전 우선순위 동작에 대해 일관된 방향을 유지하고 끈기 있게 소통해 온 점에서 큰 찬사를 받을 만합니다.

Copyright

This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.