/cc @uranusjr @ncoghlan @altendky @njsmith

나는 이것이 일반적으로 발생하는 일이라고 확신합니다(기업 FW/캐싱 프록시) -- PIPENV_PYPI_MIRROR 와 같이 pipfile에서 찾을 경우 pypi 대신 사용할 미러를 지정하기 위해 재정의 설정이 필요하다고 생각합니다. PIPENV_PYPI_CACHING_PROXY 또는 이와 유사한 것을 먼저 시도해야 함을 지정하고 기본적으로 pypi 앞에서 sources 로 슬라이스합니다.

그것이 목표를 달성한 것처럼 보입니까? 그렇다면 구현 지니에 태그를 지정하여 이것이 좋은지 나쁜지 알려줄 수 있습니다(@ncoghlan).

주의 사항부터 시작하겠습니다. PyPI가 PyPI에서 공칭한 패키지가 실제로 PyPI가 게시한 것과 일치하도록 pip 에 TLS 독립적인 방법을 제공하기 위해 PEP 458과 유사한 패키지 서명 메커니즘을 구현할 때까지 , 트래픽을 투명하게 다른 서버로 리디렉션하는 기능을 제공하는 것은 보안 관점에서 진정으로 우려되는 사항입니다.

불행히도 그 특정 공격 벡터는 이미 pip.conf 를 통해 열려 있으므로 pipenv 수준에서 비슷한 것을 제공한다고 해서 지금보다 더 나빠지지는 않을 것입니다.

그 외에도 범용 리포지토리 URL 재작성 메커니즘은 적어도 기본 기능 계층에서 PyPI에 특정한 것보다 실제로 문서화하고 설명하기가 더 쉬울 수 있다고 생각합니다. 다음과 같은 것:

pipenv --override-source-url 'default=https://pypi-proxy.example.com/api' --override-source-url 'https://pypi.python.org/simple=https://pypi-proxy.example.com/api'  --override-source-url 'https://pypi.org/simple=https://pypi-proxy.example.com/api' install

(유일한 PyPI 특정 비트는 pip.conf 에 명시된 대로 pip의 기본 다운로드 소스를 참조하기 위해 "default"를 사용합니다).

매번 전체 소스 URL 재정의 맵을 철자하는 것은 실제로 사용하기에는 다루기 힘들 수 있으므로 CLI 설탕에 대한 몇 가지 옵션은 다음과 같을 수 있습니다.

pipenv --override-source-urls <config file> install

pipenv --pypi-mirror https://pypi-proxy.example.com/api install

--override-source-url 레이어를 즉시 노출할지 여부는 다른 질문입니다. 먼저 더 간단한 --pypi-mirror 옵션을 구현하고 --override-source-url 및 --override-source-urls 는 그렇게 하는 동안 염두에 두고 가능한 미래 옵션입니다.

일반적인 {given URL: override URL} 매핑도 내 첫 번째 생각이었지만 추가 고려 사항에 따라 특수 케이스 PyPI에 대한 몇 가지 주장이 있습니다.

• PyPI는 잘 알려진 공개 URL 과 많은 미러를 가지고 있다는 점에서 매우 독특합니다.

• https://pypi.python.org/simple/ 에는 https://pypi.org/simple/ 여러 https://pypi.org/simple URL이 있습니다 https://pypi.python.org/simple https://pypi.org/simple/ 후행 슬래시?), 각 사용자가 스스로 알아내도록 하는 대신 이 문제를 한 번만 해결할 수 있다면 좋을 것입니다.

@njsmith 내 게시물의 마지막 부분에서 --pypi-mirror <URL> 설탕 제안을 참조하십시오. 초기 구현이 그것에만 초점을 맞춘 경우 일반 URL 재작성 기능은 내부 구현 세부 사항으로 시작할 수 있습니다(" PyPI"에는 궁극적으로 모두 동일한 위치로 확인되는 여러 URL이 있으며 나중에 그 자체로 기능으로 노출되는 것으로 간주됩니다(기본 --pypi-mirror 사용에 대해 원하는 대로 작동하는 것으로 확인된 후). 사례).

아 맞다, 놓쳤어 :-)

명령줄 인수를 보다 영구적인 구성에 매핑하는 일반적인 규칙이 있습니까? 나는 이것의 대부분의 사용자가 그것을 한 번 설정하고 잊어 버리기를 원할 것이라고 상상합니다.

@ncoghlan 은 다음과 같이 썼습니다.

주의 사항부터 시작하겠습니다. PyPI가 PEP 458과 유사한 패키지 서명 메커니즘을 구현하여 명목상 PyPI에서 시작된 패키지가 실제로 PyPI가 게시한 것과 일치하도록 pip에 TLS 독립적인 방법을 제공할 때까지 다음 기능을 제공합니다. 트래픽을 투명하게 다른 서버로 리디렉션하는 것은 보안 관점에서 진정으로 우려됩니다.

내 Pipfile.lock 를 올바르게 읽고 있다면 패키지와 패키지가 설치된 소스 간에 저장된 관계가 없습니다. 기존 기능 집합에서 여러 소스를 지정할 수 있다는 점을 감안할 때 비슷한 문제가 발생하지 않습니까? sync 는 잠금 파일을 생성할 때 사용한 것과 다른 소스에서 패키지를 가져오는 결과를 초래할 수 있습니다.

Pipfile.lock 는 고정된 각 종속성에 대해 허용되는 아티팩트 해시 목록을 저장하므로 일단 잠금을 완료 하면 비밀리에 패키지를 교체하기가 어렵습니다. 잠금 생성 시 Pipfile 의 소스에 명시적으로 옵트인하는 것은 "나는 이 소스가 나를 망치지 않을 것이라고 신뢰하며 TLS를 사용하여 내가 실제로 이 원점과 대화하고 있는지 확인합니다"라고 말합니다. (여기가 아닌 pip 또는 다른 PyPA 저장소 중 하나에 있을 수 있지만 특정 패키지를 특정 소스 저장소에 바인딩할 가능성에 대해 논의하는 어딘가에 문제가 있다고 생각합니다.)

pip.conf 에서 기본 색인 URL을 변경하거나 추가 색인 URL을 추가하거나 구성 파일 또는 셸 프로필 기반 메커니즘을 통해 여기에 제안된 재정의 기능을 사용하는 것은 다릅니다. 내 홈 디렉토리(예: sdist의 setup.py 파일)에 대한 쓰기 액세스 권한으로 특정 시점에 실행되어 이 패키지 소스를 신뢰하도록 설정을 구성하기로 결정했습니다." 그리고 PEP 458과 같은 서명 체계도 확인에 사용되는 공개 키 자체가 수정을 위해 높은 권한이 필요한 디렉토리가 아닌 홈 디렉토리 내부 어딘가에 저장되어 있는 경우 이러한 종류의 속임수에 대한 완전한 방어가 아닙니다.

엄격한 보안 요구 사항을 가진 조직이 일반적으로 인터넷에 대한 액세스가 제한된 잠긴 서버에서 빌드를 실행하거나 네트워크 수준에서 이러한 종류의 문제를 모니터링하는 데에는 충분한 이유가 있습니다.

또한 여러 인덱스를 사용하고 패키지가 기본이 아닌 인덱스에서 가져온 경우 잠금 파일에 표시됩니다.

pep 458 문제는 본질적으로 내가 염두에 두었던 것입니다. URL은 다르지만 실제로 pypi의 지점은 로컬에서 pypi를 복사하고 동일하다고 주장하는 경우와 다르기 때문입니다.

나 또는 내 홈 디렉토리(예: sdist의 setup.py 파일)에 대한 쓰기 액세스 권한으로 특정 시점에 실행한 임의의 프로세스가 이 패키지 소스를 신뢰하도록 설정을 구성하기로 결정했습니다.

이것이 위협 모델인 경우 pipenv가 수행할 수 있는 작업이 큰 영향을 미칠지 모르겠습니다. 홈 디렉토리 구성을 수정할 수 있는 사람은 $PATH 에 새 디렉토리를 삽입하고 원하는 작업을 수행하는 가짜 pipenv를 삽입하는 것과 같은 작업을 수행할 수도 있습니다.

@njsmith 이것은 pip의 위협 모델이기도 합니다. 패키지 설치는 sdist setup.py 파일에서 임의의 코드를 실행해야 하기 때문입니다. 그 코드는 실제로 설정과 같은 홈 디렉토리의 항목을 덮어쓰거나 경로에 항목을 추가하거나 여러 가지를 할 수 있습니다. 그렇기 때문에 명시적으로 pypi(알고 신뢰할 수 있는 인덱스)에 권한을 부여하고 해시 검사를 요구하는 것이 보안을 위한 좋은 단계입니다. 이를 통해 알려진 보안 위협을 중앙 집중식으로 제어 및 제거하고 다운로드 중인 패키지를 분산 방식으로 검증할 수 있습니다. 다운로드한 잠금 파일은 받아야 하는 해시에 대해 무엇이라고 말했습니까? 색인에서 얻은 것과 일치하지 않습니까? 이 작업 모드가 실패하려면 로컬 시스템, 인덱스 및 네트워크 계층 중 하나 이상에서 오류가 발생해야 합니다. 신뢰할 수 있는 인덱스에 대해 해시를 확인하는 작업을 함께 수행하는 애플리케이션 스택에서 여러 손상된 패키지를 갖는 것에 대해 이야기하고 있기 때문입니다. , 그리고 많은 경우 해시 자체는 관련되지 않은 또 다른 소스에서 왔습니다. 이제 최소한 pip와 pipenv의 모든 해시 검사가 어떻게든 변조되어 원하는 것과 동일한 해시를 생성하지만 다른 악의적인 것을 설치해야 합니까?

내 말은 로컬 시스템이 손상된 경우 pip 또는 pipenv가 사용자를 구하기 위해 할 일이 없다는 것입니다. 그러나 우리는 당신이 다운로드하고 있는 패키지가 당신이 그것을 검색하기로 되어 있는 곳에서 당신이 찾고 있던 패키지라는 것을 확신할 수 있습니다. 이것은 보안 사슬에서 하나의 요소를 제공할 수 있습니다.

@ncoghlan @njsmith 이 모든 요소가 sudo pip install... 에 대한 반발 움직임과 일반적인 의미에서 pip를 사용하려는 경우 시스템 패키지 관리자는 파이썬을 광범위하게 설치합니다. 이것은 실제로 pipenv 질문은 아니지만 지금 토론이 진행되고 있는 곳이며 다음 단계를 안내할 수 있습니다...

@techalchemy 이 주제에 대한 연결이 전혀 보이지 않습니까? 위의 모든 것의 결론은 사용자가 PyPI에 대해 pipenv가 사용하는 미러를 재정의하도록 하면 추가 위협이 발생하지 않으며 sudo pipenv 를 수행하는 것은 애초에 의미가 없다는 것입니다. 그렇죠?

@njsmith 아니요 sudo pipenv 를 사용해서는 안 된다고 생각합니다. 제가 언급한 것처럼 실제로 주제가 아니지만 위협 모델 경로를 약간 따라갔기 때문에 탐색할 가치가 있다고 생각했습니다. 구체적으로:

그리고 PEP 458과 같은 서명 체계도 확인에 사용되는 공개 키 자체가 수정을 위해 높은 권한이 필요한 디렉토리가 아닌 홈 디렉토리 내부 어딘가에 저장되어 있는 경우 이러한 종류의 속임수에 대한 완전한 방어가 아닙니다.
엄격한 보안 요구 사항을 가진 조직이 일반적으로 인터넷에 대한 액세스가 제한된 잠긴 서버에서 빌드를 실행하거나 네트워크 수준에서 이러한 종류의 문제를 모니터링하는 데에는 충분한 이유가 있습니다.

최소한 어느 정도의 방어가 권한 있는 위치에 저장된 키에 의존하지만 권한 있는 python 설치를 사용하지 말라고 조언하는 경우 논의할 가치가 있다고 생각합니다. 내가 틀렸을 수도 있습니다. 그러나 그것은 확실히 @ncoghlan 의 의견과 관련이 있는 것 같습니다 (그러나 sudo pipenv , 그것은 절대 되어서는 안 됩니다)

네, 그냥 갑자기 떠오른 생각인 것 같습니다. 추가 컨텍스트가 일부 해결되기를 바랍니다.

나는 우리가 TUF를 구현할 수 있는 방법에 대한 추측적인 토론에 참여하기 보다는 PyPI 미러를 사용해야 하는 사람들을 돕는 주제에 이 문제를 유지하는 데 투표합니다. (어쨌든 사용자의 홈 디렉토리에 대한 임의의 쓰기 액세스 권한을 가진 공격자를 방어하기 위해 우리가 할 수 있거나 해야 하는 일이 많지 않다고 생각합니다.)

자, 이제 우리가 기대하거나 선호하는 동작을 정의해 보겠습니다. 나의 현재 작업 이해는 다음과 같습니다.

• --pypi-mirror 가 전달되거나 PIPENV_PYPI_MIRROR 가 설정되면 다음을 선호해야 합니다.
• PyPI보다 더 선호해야 합니까? 주어진 인덱스 URL이 'PyPI'인지 여부를 어떻게 평가합니까? 쿼리할 수 없으므로 목록을 유지해야 합니다.
• 목록에 가능한 모든 순열이 포함되어야 합니까, 아니면 제공된 미러를 먼저 시도해야 하는 것으로 Pipfile을 생성하기 위해 과거에 사용한 두 개의 URL을 사용하는 데 만족해야 합니까?

다른 URL이 아닌 PyPI만 재정의해야 합니다. 아마도 몇 가지 다른 PyPI URL이 사용 중일 것이므로 나열할 수 있으며, 하나를 놓치면 누군가 버그를 신고하고 추가될 것이며 곧 모든 URL을 갖게 될 것입니다.

저에게 맞는 접근인 것 같습니다.

@njsmith 가 말한 것은 내 관점과도 일치합니다. 초기 PR에서 교체할 것을 제안하는 3개의 repo URL은 다음과 같습니다.

• 설정되지 않음(즉, pip 의 기본 설정에 의존하는 경우)
• https://pypi.python.org/simple
• https://pypi.org/simple

후행 슬래시 여부는 URL을 별도로 나열하는 것보다 URL 정규화 단계로 처리하는 것이 좋습니다.

요청 Pipfile에는 후행 슬래시(작성 시) 가 있으므로 이 방법 또는 다른 방법으로 처리해야 할 수 있습니다.

맞다, 내 생각은 이랬다.

• 후행 슬래시 없이 URL 목록 유지
• 들어오는 URL에 후행 슬래시가 있는지 확인하고 발견되면 제거하십시오( str.rstrip 는 임의의 수의 후행 슬래시를 제거하더라도 작업에 충분할 것입니다. 그렇지 않으면 이에 대해 더 엄격할 수 있습니다. 그리고 최대 하나의 후행 슬래시를 제거하십시오)

엄청난. 나는 이것이 작업하기에 충분하고 구축하기에 충분히 간단하다고 생각합니다. 모두 감사합니다!

미러 기능이 빨리 추가되었으면 합니다~

이 문제도 발생합니다. 상황은 다음과 같습니다.

• 일부 개인 패키지가 포함된 내부 PyPI 서버가 있습니다.
• Pipenv를 사용하여 종속성을 관리하는 여러 Python 애플리케이션이 있습니다.
• 일부 종속성은 내부 PyPI 서버에 있고 다른 종속성은 커뮤니티 PyPI에 있습니다. 내부 패키지는 찾을 수 없는 패키지에 대해 커뮤니티 PyPI로 리디렉션됩니다.

내 배포 전략은 이미 내부 PyPI 서버를 참조하는 시스템 전체 pip.conf를 설정합니다. 놀랍게도 이 구성은 Pipenv에서 무시됩니다.

내부 PyPI를 이동/이름 변경하려면 Pipfiles가 있는 여러 응용 프로그램을 업데이트하고 해당 Pipfile.lock 파일을 다시 생성해야 합니다. 미러 옵션은 원하는 기능을 제공합니다. Pipenv가 Pip에 대한 시스템 구성을 읽을 수만 있다면 작동하고 덜 중복되는 느낌이 들 것입니다.

PR 환영합니다 btw

안녕. 저에게도 같은 요구 사항이 있지만 이 무시 기능을 다른 티켓으로 분할하고 싶습니다.

예상되는 행동 제안은 다음과 같습니다.

• 구성 파일은 Pipfile의 [[source]] 섹션에 정의된 모든 값을 설정하도록 정의할 수 있습니다.
• Pipfile의 [[source]] 섹션만 있는 toml 파일일 수 있습니다.
• 이 파일의 위치는 pip.conf(예: /etc/pipenrc.toml, ~/.pipenvrc.toml)에 대해 정의된 규칙에서 크게 영감을 받았습니다.
• 환경 변수는 이러한 값을 재정의하도록 정의할 수도 있습니다(알림: [[source]]의 모든 값이 필요함). 정의
• pipenv의 현재 동작은 다음과 같습니다.
  
  
  
  • Pipfile을 생성할 때 구성 파일/환경 변수에서 값을 가져옵니다.
  
  
  • 구성 파일이나 환경 변수가 정의되지 않은 경우 pipenv의 현재 동작이 적용됩니다.
  
  
  • pipenv는 항상 Pipfile의 [[source]] 섹션을 계속 생성합니다.
  
  
  • Pipfile의 [[source]] 섹션이 존재하는 경우 pipenv는 구성 파일의 값으로 무엇이든 재정의하지 않습니다.
  
  

그리고 두 번째 티켓에서 —재정의 옵션을 구현할 수 있습니다. 예를 들어 CI 또는 기타 내부에서 의미가 있습니다.

참고로 우리는 현재 프로덕션에서 pipenv를 많이 사용하지만 Arrifactory Pypi 저장소에 도달하기 위해 새 프로젝트를 시작할 때 Pipfile을 수동으로 변경해야 한다는 점을 모든 사람에게 너무 자주 상기시켜야 합니다(참고로 Nexus는 Pypi도 수행합니다. 무료로 캐시하고 t는 훌륭하게 작동합니다!). 우리는 매우 제한적인 방화벽을 가지고 있으며 회사 내부에서 외부 종속성을 캐시하는 것은 매우 좋은 방법이므로 백업하고 취약점을 확인할 수 있습니다.
일반 또는 사용자 구성 파일과 유사한 간단한 기능(예: pip 또는 npm에 대해 이미 수행한 것과 같이)으로 모든 워크스테이션에 배포하여 개발자가 실수를 덜 하도록 하는 경우 저에게 완벽할 것입니다.

내가 뭔가를 놓쳤을 수도 있지만 이것은 회귀처럼 보입니다. 우리는 잠시 동안 11.6.0을 사용했고 pipenv는 내부 pypi 미러를 가리키는 pip.conf의 설정에 기꺼이 위임했습니다.

이게 언제 고장났는지 아세요? 이것은 우리 컨텍스트에서 pipenv를 완전히 사용할 수 없게 만듭니다. 오랫동안 정상적으로 작동하던데 이것을 "누락된 기능"으로 보는 데 문제가 있습니다.

분명히 하자면: 2018.05.18로 업그레이드한 후 Pipfile[.lock]에 지정된 미러를 사용하더라도 pipenv는 pypi.org에서 새 패키지를 설치하려고 시도합니다.

내가 보고 있는 것은 이 문제와 별개의 문제일 수도 있습니다.

@brettdh 본인의 환경을 보지 않고는 구분하기 어렵지만 같은 문제는 아니라고 생각합니다. 릴리스 간에 이등분하여 정확히 어디가 변경되었는지 확인하고 이에 대한 새 문제를 여는 것이 좋습니다.

이를 위해 PR을 하고 있습니다.

나는 이것이 기본 설정에 비해 퇴행되었다고 생각합니다. 아직 출시되지 않은 pip 10 업데이트의 물결에 휩싸였을 수 있지만 @JacobHenner 가 아직 추가하지 않은 경우 큰 어려움 없이 이를 선택할 수 있다고 믿습니다.

공식 PyPi의 캐싱 프록시로 devpi를 사용하는 것에 대해 이야기하고 있다고 가정합니다. pip 자체의 경우 pip가 모든 요청에 ​​대해 로컬 devpi 서버를 사용하도록 /etc/pip.conf 및 /usr/lib64/python3.6/disutils/distutils.cfg 를 수정해야 합니다.

그러나 pipenv는 이러한 시스템 전체 설정을 무시 하는 것처럼 보이므로 devpi 서버를 참조하도록 Pipfile의 [[source]] 구성 설정을 수정해야 합니다. 그러나 Pipfile을 외부에 게시하면 외부 기여자가 실제로 자신의 환경을 구축하기 위해 [[source]] 설정을 제거해야 합니다.

pipenv는 /etc/pip.conf 및 /usr/lib.../distutils.cfg 의 전역 설정을 존중해야 한다고 생각합니다.

@polski-g

공식 PyPi의 캐싱 프록시로 devpi를 사용하는 것에 대해 이야기하고 있다고 가정합니다.

넥서스 저장소, 하지만 같은 생각입니다.

그러나 pipenv가 이러한 시스템 전체 설정을 무시 하는 것 같습니다.

@techalchemy가 언급했듯이 pipenv(11.6.0)는 pip.conf (homedir도 마찬가지)를 존중했지만 최신 버전은 그렇지 않다고 생각합니다. 특히 하드 코딩된 pypi.org URL이 어딘가에 있습니다(종속성 resolution, IIRC) 재정의할 수 없습니다.

pipenv는 /etc/pip.conf 및 /usr/lib.../distutils.cfg의 전역 설정을 존중해야 한다고 생각합니다.

동의합니다. 개인적으로 사용 사례에서 distutils.cfg 를 수정할 필요가 없었습니다.

IIRC에는 pip.conf를 존중하지 않는 해결 방법이 있었지만 이를 찾으려면 문제 추적기를 자세히 살펴봐야 합니다. 어쨌든 배는 항해했고 PyPI 미러링이 거의 완료되었으므로 가까운 장래에 변경되지 않을 것입니다.

나는 이 기능이 다음 릴리스에 출시될 것이라고 확신합니다.

또한 이것에 대해 잘 모르겠지만 구성 기본값을 가져오기 위해 여기서 구성 파서를 생성한 후 .load() 를 호출해야 할 수도 있습니다.

https://github.com/pypa/pipenv/blob/master/pipenv/project.py#L573 -#L577

@uranusjr 미러링 구성이 작동하는 한(즉, 내가 언급한 하드코딩된 pypi.org URL을 사용하지 않음) pipenv가 이에 대한 자체 구성을 갖고 pip를 무시하는 데 문제가 없습니다.

@brettdh 내 지점을 확인하고 귀하의 요구 사항을 충족하는지 확인할 수 있습니까?
귀하의 환경에서 사용 사례?

>

@JacobHenner 네, 감사합니다. --pypi-mirror 옵션( pipenv install , pipenv lock )을 사용한 초기 테스트는 제대로 작동하는 것 같습니다. PR에 작은 제안을 남겼습니다.

하지만 pypi.org에 대한 하드코딩된 URL이 여전히 pipenv 소스에 흩어져 있는 것처럼 보이는 것이 약간 걱정됩니다. [[source]] 항목에서 어떤 항목이 올바르게 재정의되었는지 확신할 수 없으며 위의 문제를 일으킨 워크플로가 정확히 기억나지 않습니다. 그래서 고쳐졌다고 말씀드리기 어렵습니다. 😬

예, 이번 릴리스 이후에 주요 코드 정리를 계획하고 있습니다. Cli 항목을 cli로 이동하고 예외를 버블링하고 그곳에서 모든 종료를 처리하고 중복 코드를 중복 제거하는 등 많은 작업이 필요할 것이며 자원 봉사를 원하는 사람이 있다면 도움을 주시면 감사하겠습니다.

방금 최신 버전을 가져왔고 여전히 소스에서 pypi.org를 하드코딩하고 있습니다. 목표는 환경 변수 또는 pypi-mirror를 가져 와서 [[source]]의 기본값으로 두는 것입니까?

편집하다:

방금 코드를 파헤 쳤습니다 .. 당신이 가지고있는 것 같습니다

if PIPENV_TEST_INDEX:
    DEFAULT_SOURCE = {
        u"url": PIPENV_TEST_INDEX,
        u"verify_ssl": True,
        u"name": u"custom",
    }
else:
    DEFAULT_SOURCE = {
        u"url": u"https://pypi.org/simple",
        u"verify_ssl": True,
        u"name": u"pypi",
    }

PIPENV_TEST_INDEX를 환경 변수 PIPENV_PYPI_MIRROR로 변경했다면 좋은 시작이 될 것이라고 생각합니다.

여기에서 논의된 솔루션은 오랫동안 구현되었습니다. 인용한 스니펫은 기본값 입니다. 즉, Pipfile을 생성할 때 소스를 제공하지 않는 경우에 사용됩니다.

아니요, 소스는 Pipfile에서 변경되어서는 안 됩니다. 이번 변화의 목표
사용자가 변경 없이 _미러를 사용하여 PyPI URL을 재정의할 수 있도록 했습니다.
핍파일.

@JacobHenner 미러 처리 코드는 소스 목록을 사후 처리하고 pypi.org URL을 지정된 미러에 대한 참조로 바꿉니다 .

이것이 Pipfile 에 명시적인 pypi.org 항목이 있는 경우에도 미러 재정의가 작동하도록 하는 것입니다. pipenv 는 동일한 논리를 사용하여 자체 기본 소스도 재정의합니다.

현재 해당 후처리가 올바르게 적용되지 않는 경우가 있다면 기능 요청이 아니라 이미 구현된 기능에 대한 새로운 버그 보고서입니다.

마지막 댓글은 @kylecribbs를 위한 것 같은데요?

@JacobHenner 아, 죄송합니다. 이 변경 사항이 원래 목표를 달성하지 못했다고 귀하의 의견을 잘못 해석했습니다. 그 결과가 실제로 무엇인지 명확히 하려는 Kyle의 답변이 아닙니다.