동의. 의존성 링크에 대한 pip의 현재 동작은 정말 짜증납니다.

4295

3610

[#3939에 작성, 내 의견을 여기로 이동]

여기 주요 문제가 있습니다. requirements.txt 파일을 사용하고 싶지 않다면 (예를 들어, setup.cfg 에 모두 지정된 선언적 종속성을 원하기 때문에), URL을 종속성으로?

이것은 작동하지 않습니다:

[options]
install_requires = 
  requests==2.18.4
  https://github.com/example/example_lib/archive/master.zip

또한 종속성 링크를 삭제하는 것이 이상하고 괜찮다고 생각하지만 표준적 으로 이 사용 사례가 없으면 어떻게 제공됩니까?

또 다른 문제는 dependency_links 분명히 setup.cfg에서 setup.py 인수로만 지정할 수 없다는 것입니다. 더 이상 사용되지 않는 경우 수정해야 합니다.

이에 관한 소식이 있습니까? 진행 중인 대안이 있습니까? dependency_links_는 라이브러리의 내부/개인 배포를 위한 유일한 옵션인 것 같습니다.

더 이상 사용하지 않는 대신 수정해야 합니다. 많은 사람들이 install_requires에 라이브러리의 이름 버전과 계란과 함께 tarbal이 포함된 종속성 링크를 모두 넣는 것을 잊어버리기 때문에 잊어버리거나 혼동합니다. 대안으로 @jleclanche 가 install_requires에서 tarball에 대한 간단한 링크를 제안한 것을 보고

나는 우리가 혼자라고 생각하지 않습니다: https://stackoverflow.com/questions/3472430/how-can-i-make-setuptools-install-a-package-thats-not-on-pypi

devpi 와 같은

@dstufft btw - devpi의 존재가 종속성 링크를 불필요하게 만드는 문제에 대한 보다 깨끗한 솔루션을 보여주고 있다고 주장하고 싶습니다.

IMHO 인덱스 상속 + 화이트리스트/블랙리스트 작성은 운영 수준에서 보다 일관되고 이해하기 쉽습니다.

@RonnyPfannschmidt , 제안에 감사드립니다. 중요한 것을 놓치고 있는 것 같지만(이 지원 중단에 대한 논의가 너무 오래 진행되어 왔습니다) 일반적으로 말하면 reddit의 이 의견에 더 동의할 수 없습니다.

devpi가 해결책이 될 수 있지만 유지 관리가 필요하고 일부 관리자가 설정하기를 기다려야 하는 다른 서비스를 게임에 도입하는 것은 곧 작업에 착수하지 못할 것입니다. 또한 우리는 여전히 패키지를 빌드한 다음 devip에 넣을 필요가 있습니다(또는 devpi에 git 저장소를 추적하는 기능이 있나요?)

이상적으로는 라이브러리에 파일을 추가하거나 setup.py에 몇 줄을 추가하는 것 이상을 필요로 하지 않는 대안이 필요합니다.

나는 기본적으로 그것을 제거하는 근본적인 결정을 이해하지 못하고 그것이 어떻게 나쁜 관행과 불안으로 이어질 수 있는지 알 수 있지만 내부 사용을 위해 유지하는 한 주요 문제는 아닙니다.

4175는 PEP 508 URL 지원이 pip 10에 있음을 의미합니다. 이것이 닫힐 수 있다고 생각합니다.

@pfmoore @dstufft?

https://github.com/pypa/pip/pull/4175/commits/86b07792e7ae762beeaeb471ab9db87e31bc285d 는 @ 구문을 종속성에 사용할 수 없다는 것을 의미하므로 #4175가 이 문제에 대한 해결책이 아니라고 생각했습니다. . 거기에 대한 의견은 PyPI가 이를 사용하는 업로드를 차단할 수 있을 때까지 종속성에 대한 @ 지원을 구현해서는 안된다는 것이었습니다. , 아마도).

PEP 508 지원과 같은 대안이 있을 때까지 더 이상 사용되지 않아야 합니다. 그때까지 너무 많은 사람들이 그것을 사용하고 있습니다.

이에 대한 적절한 워크플로는 무엇입니까?

기능을 추가해야 하는 라이브러리가 있다고 가정해 보겠습니다. Github에서 포크합니다. 기능은 곧 병합되지 않을 예정이므로 PyPi 대신 Github 포크를 사용하도록 설정한 도구가 있습니다.

이제 모든 사용자는 더 이상 사용되지 않으며 한 번 제거된 플래그인 pip를 사용하여 도구를 설치할 때 --process-dependency-links를 추가해야 합니까?

내가 놓치고 있는 몇 가지 옵션이 setup.py에 있습니까? 아니면 이 문제를 해결할 수 있는 방법이 없나요? 이를 수행하는 유일한 실행 가능한 방법은 분기된 pypi 패키지를 푸시하는 것 같습니다. 어쨌든 pull 요청이 병합되면 사용자의 혼란을 가중시킬 것입니다.

이것으로 가자.

--process-dependency-links 에는 오늘날 대안이 없습니다. 따라서 계속해서 사용하지 않는 것이 좋습니다.

그러나 플래그는 pip가 임의의 URL에 도달한다는 것을 의미합니다. 이에 대한 경고가 첨부되어야 합니다.

@pradyunsg 영원히 죽일 계획이 없는 한, 좀비를 쉬게 하거나 제거할 것을 강력히 제안합니다.

나는 pip가 "아니오, 나는 당신의 빚을 지지 않습니다"라고 말하지 않는 한 실제로 그것을 필요로 하는 사람들이 상황을 고칠 동기가 있다고 생각하지 않습니다.

pip 유지 관리자로서 내 관심사는 pip가 악용의 벡터가 되는 것을 허용하지 않는 것입니다. Pip는 PyPI를 기본 인덱스로 가정하므로 PyPI에 대한 암시적 신뢰가 있습니다. 그래서 내 첫 번째 질문은 다음과 같습니다.

1. dependency_links 메타데이터가 있는 패키지가 PyPI에 있습니까?
2. dependency_links 가 있는 프로젝트의 업로드를 거부하도록 PyPI를 수정할 수 있습니까(또는 이미 그렇게 합니까)?
3. 또는 pip가 PyPI에서 다운로드한 패키지에 대한 종속성 링크(옵션 설정 여부에 관계없이) 처리를 거부할 수 있습니까?

pip 사용자가 악성 dependency_links PyPI 패키지에 물릴 수 있는 방법이 없다고 확신할 수 있다면 덜 걱정할 것입니다. 사용자 지정 인덱스를 사용하기로 선택한 사용자는 이를 신뢰할지 여부를 스스로 결정해야 합니다. (나는 그때에도 플래그를 유지하는 것을 선호합니다. 이것은 잠재적으로 원격 악용이며 항상 명시적으로 옵트인해야 합니다).

따라서 다음과 같은 변경 사항이 있습니다.

1. Pip는 PyPI의 종속성 링크를 절대 처리하지 않습니다(명시적으로 또는 존재하지 않는다는 것을 알고 있기 때문에).
2. --process-dependency-links 플래그는 더 이상 사용되지 않지만 사용자 정의 인덱스에서만 작동합니다.

나는 그것을 현상태로 받아들이는 것이 좋다. 의존성 링크 스타일 기능을 필요로 하는 사람들은 앞으로 나아가고자 하는 방식(만약 있다면)을 서로에게 덤벼들 수 있습니다.

누군가가 원한다면 이 모든 것을 종속성 링크 메타데이터를 정의하는 표준에 넣을 수 있으며 현재 사용 중단은 "표준에 지정된 동작을 위해 현재 동작이 삭제됩니다"가 됩니다. 그러나 pip 중심적인 관점에서 보면 저는 그냥 그렇게 하고 싶습니다. 종속성 링크가 필요한 사람들이 표준화 작업을 하도록 하십시오(결국 자신에게 이익이 됩니다. 경로가 있기 때문에 표준 변경을 얻는 것) - 완전한 커뮤니티 합의로 pip의 행동을 수정하기 위해).

기본적으로 우리는 의존성 링크를 대체하기 위한 기능을 가지고 있지만 pip는 아직 그것을 사용하기 시작하지 않았습니다. 왜냐하면 우리는 아직 그것을 사용하는 PyPI에 대한 업로드를 차단할 방법이 없기 때문입니다.

#4175를 의미합니까? 86b0779 때문에 차단된 것은 무엇입니까? comes_from 가 PyPI인 경우에만 오류가 발생하도록 https://github.com/pypa/pip/blob/master/src/pip/_internal/req/req_install.py#L167 을 수정할 수 있습니까?

그런 다음 --process-dependency-links 에 대한 사용 중단 경고를 변경하여 사용자가 @ 구문으로 전환하고 합리적인 사용 중단 기간이 지나면 --process-dependency-links 를 삭제해야 합니다. @ 구문을 사용할 수 있게 된 시점부터 시계가 똑딱 거리고 있음).

@pfmoore 예, 바로 그것이며, 앞으로 나아갈 수 있는

확인. 다른 사람이 먼저 접근하지 않으면 PR 작성에 대해 알아보겠습니다.

내가 수집한 정보에서 사용자 문제는 대안이 없는 기능에 대해 옵션을 전달할 때 "헤이, 사용되지 않습니다."라고 명시적으로 말하는 옵션을 전달해야 한다는 것입니다.

사용 중단 기간 동안 종속성_링크 지원을 완전히 중단하는 데 찬성합니다. 그리고 그 사이에 PEP 508 URL 종속성 지원을 추가했는데, pip를 사용할 때 여전히 큰 소리를 내야 하고 여전히 옵트인 상태여야 한다고 생각합니다.

이는 다음을 의미합니다.

• 플래그 뒤에 PEP 508 url-deps를 처리하는 기능을 넣습니다.
  
  
  
  • 제쳐두고: 보안 관련 사용자가 문서를 확인할 수 있도록 플래그의 이름을 지정해야 합니다.
  
  
• PyPI 패키지에서 가져온 PEP 508 url-deps 설치를 거부하기 시작합니다.
• 종속성 링크는 더 이상 사용되지 않지만 삭제할 날짜가 있습니다.
  
  
  
  • 솔직히 말해서, 대안을 인쇄하는 단일 릴리스보다 더 이상 사용 중단 기간을 제공하고 싶지 않습니다.
  
  

어제 타이핑했는데 안 보냈어요. 이제 @pfmoore 의 마지막 댓글과 기본적으로 동일하다는 것을 깨달았습니다.

_야!

URL deps에 옵트인 플래그가 필요합니까? PEP 508은 그렇게 말하지 않으며 현재 구현에서는 그렇게 하지 않습니다. 논리는 알 수 있지만 보안 대 사용 용이성 질문에 대한 내 판단을 신뢰하지 않습니다.

또한 스위치를 푸시하기 전에 프로젝트가 종속성 링크에서 @ 구문으로 전환하는 방법에 대한 명확한 문서를 보고 싶습니다. 지원 중단의 영향을 받을 사람들에게 도달하는 것은 이미 충분히 어렵고, 해결 방법을 찾을 수 없다는 경고는 도움이 되지 않습니다. 이상적으로는 경고에 "변경 방법" 문서인 IMO에 대한 포인터가 포함되어야 합니다.

나는 보안 대 사용 용이성 질문에 대한 나의 판단을 신뢰하지 않습니다.

저는 "기본적으로 보안을 유지"하고 덜 안전한 행동을 선택하는 경향이 있습니다.

스위치를 푸시하기 전에 프로젝트가 종속성 링크에서 @ 구문으로 전환하는 방법에 대한 명확한 문서

나에게 좋은 소리.

저는 "기본적으로 보안을 유지"하고 덜 안전한 행동을 선택하는 경향이 있습니다.

내 직장에서 방화벽 및 보안 제약을 처리하기 위해 열심히 일하는 사람으로서 나는 이 기능이 가장 유용할 것 같은 환경(내부 개발, 폐쇄 소스 , 엄격하게 제어되는 워크플로 및 네트워크 레이아웃 등). 따라서 내 성향은 기본 워크플로(PyPI)에 대해 안전하지만 워크플로에 분명히 중요한 사용 사례를 가진 사람들을 방해하는 추가 장애물을 두지 않는 것입니다. 만들다.

내 생각에 "패키지가 명시적으로 사용하기로 선택한 서버에서 오는 경우"는 URL 링크를 허용하기에 충분합니다.

보다? 미소 : 그것은 내가 확실히 내 편견이 표시되지 않는 아니에요 단지, 의견이없는 것이 아니다 :

워크플로에 분명히 중요한 사용 사례를 가진 사람들을 방해하는 추가 장애물을 두어서는 안 됩니다.

그럴 수 있지. 일부 사용자가 워크플로에 대한 통찰력을 제공할 수 있다면 좋을 것입니다.

"패키지가 명시적으로 사용하기로 선택한 서버에서 오는 경우"는 URL 링크를 허용하기에 충분합니다.

잘 모르겠습니다. :/

보다? 제 의견이 없는게 아니라 제 편견이 잘 드러나지 않는 것 같아요 😄

헤헤.

그럴 수 있지. 일부 사용자가 워크플로에 대한 통찰력을 제공할 수 있다면 좋을 것입니다.

내 생각에 "패키지가 명시적으로 사용하기로 선택한 서버에서 오는 경우"는 URL 링크를 허용하기에 충분합니다.

GitHub에서 소스를 허용하는 것만으로도 문제의 99%를 해결할 수 있습니다. 업스트림 패키지에는 버그 또는 누락된 기능이 있습니다. 나는 그것들을 포크하고 수정하고, PR을 발행한 다음, 병합되어 PyPI에서 릴리스될 때까지 아마도 정말 오랜 시간을 기다립니다. 그동안 내 패키지는 해당 패키지의 수정 사항에 의존합니다.

한 줄에서 수행할 수 있는 한 옵트인할 수 있습니다.

직접 링크를 사용하는 것은 보안 문제가 아니라(HTTPS/등으로 가정) 가용성 문제일 뿐입니다. 우리는 PyPI에서 그것들을 허용하지 않기 때문에 충분하고 다른 플래그가 필요하지 않다고 말하고 싶습니다.

내 작업에서 우리는 @pfmoore가 언급한 사용 사례 중 일부, 즉 패키지가 오픈 소스, 폐쇄 소스 등이기 전의 내부 개발에
파일 시스템 위치를 언급하는 사람의 가능한 사용 사례도 보았지만...
허용된 호스트/위치 목록을 제공하는 것이 합리적입니까? 플래그 이름은 @pradyunsg가 제안한 대로 사용자가 관련된 위험을 인식할 수 있을 만큼 충분히 설명적이어야 합니다. 아마도 --whitelisted-host ?

@masdeseiscaracteres 나는 당신이 오해했을 수도 있다고 생각합니다. 패키지가 PyPI에서 검색된 경우 @ 참조를 통해 패키지의 종속성이 지정되면 실패할 것이라고 제안했습니다. 그러나 어쨌든 PyPI에는 그러한 경우가 없어야 합니다(우리는 어느 시점에서 이를 거부할 것으로 예상하고 있으며 아직 설정할 수 없었습니다). @ 참조의 다른 모든 사용은 괜찮습니다.

https://github.com/pypa/pip/issues/4187#issuecomment -389846189에서 @pfmoore 가 설명한 대로 PR을 진행할 것 같습니다.

홍보 환영합니다. :)

변경 사항이 어렵기 때문이 아니라(설명한 대로 comes_from 에 대한 확인으로 보임), 도발하는 방법을 모르기 때문입니다. 오류가 발생했습니다(더 중요한 것은 그렇게 하는 테스트를 작성하는 방법을 모르겠습니다). 누구든지 그러한 테스트 사례의 예를 제공할 수 있다면 대단히 도움이 될 것입니다.

누구든지 그러한 테스트 사례의 예를 제공할 수 있다면 대단히 도움이 될 것입니다.

이를 보여주는 기존 테스트 test_install_pep508_with_url_in_install_requires 가 있습니다.

PyPI에서 설치할 때 오류가 발생하는 경우 URL 요구 사항이 있는 PyPI에 실제로 업로드하는 것보다 더 나은 옵션은 없습니다. 😞 이를 위해 PyPI에 패키지를 업로드했습니다. https://pypi.org/project/pep-508-url-deps/

또 다른 점은 -- comes_from 는 URL이나 경로가 아니라 'box==0.1.0 from file:///private/tmp/box' 행을 따른 문자열입니다. 이 문제를 해결하려는 사람은 이제 오류를 해결할 수 있는 더 나은 방법을 찾아 패키지의 출처에 대한 정보를 얻어야 합니다. :)

@pfmoore 이 문제는 내 마음에 가깝고 소중한 것입니다 😄 @pradyunsg 의 업로드가 당신에게 필요한 것을 제공합니까, 그리고 당신은 여전히 ​​이것을 다룰 계획입니까? 그렇지 않다면, 나는 그것에 스윙을 할 수 있습니다.

@bstrdsmkr 아니요. @pradyunsg가 말했듯이 comes_from 이 소스 URL이 아니기 때문에 생각만큼 간단하지 않습니다. 그래서 지금 언제 시간이 될지 모르겠습니다(이 기능을 개인적으로 사용하지 않으므로 우선 순위 목록에서 높지 않습니다).

위에서 언급했듯이 PR을 환영합니다 :-)

업로드된 패키지는 구현에 어떤 식으로든 도움이 되지 않으며 기능을 테스트하는 데만 도움이 된다고 덧붙입니다.

내 이해는 원하는 수정 사항이 다음과 같다는 것입니다.

if req.url and is_like(req.url, PYPI.url):
    raise

https://github.com/pypa/pip/blob/master/src/pip/_internal/req/req_install.py#L172
여기서 is_like() 는 URL이 동일한 도메인에 루트인 경우 True 반환합니다. 그 맞습니까?

응. 나도 그렇게 생각해. 그것은 코드 변경이 될 것입니다.

그리고 테스트와 NEWS 항목을 추가/업데이트해야 합니다.

나는 또한 이 변경이 문서에 대한 링크를 제공하는 사용 중단 메시지 + 사용자 가이드의 추가 섹션이 사람들에게 대안으로 전환하는 방법을 알려주는 추가 섹션을 제공할 기회를 보장하기에 충분히 중요하다고 생각합니다.

pip 유지 관리자로서 내 관심사는 pip가 악용의 벡터가 되는 것을 허용하지 않는 것입니다. Pip는 PyPI를 기본 인덱스로 가정하므로 PyPI에 대한 암시적 신뢰가 있습니다.

아니요, 명백한 신뢰가 있습니다. 그리고 종속성 IMHO에서 외부 소스 사용에 대한 보호 장치를 추가해도 상황이 개선되지 않습니다. 공개적으로 사용 가능한 VCS보다 pypi에서 맬웨어를 숨기는 것이 더 편리합니다.

IMHO 더 나은 접근 방식은 개발자의 VCS를 기본 소스로 사용하고 VCS의 내용이 pypy에서 얻은 것과 동일하다는 강력한 암호화 증거가 있는 캐싱 프록시와 VCS를 가리키는 레지스트리로 pypy를 유지하는 것입니다. 내 말은

0 등록

dev -- public key --> pypa

1 업로드 중

setuptools -- git+https:/.... --> pypa
pypi --> Tor --> give me that commit --> vcs
pypi <-- Tor <-- here -- vcs
pypi checks the signature matches the dev

2 유휴:

pypi --> Tor --> give me that commit --> vcs
pypi <-- Tor <-- here -- vcs
pypi checks it

2 검색 중

flips a coin
if coin == 1:
  pip -- give me package git+https:/... --> pypi
  pip <-- signature || content -- pypi
  pip -- give me the signature --> vcs
  pip <-- signature -- vcs
else:
  pip -- give signature of package git+https:/... --> pypi
  pip <- signature -- pypi
  pip --> Tor --> give me that commit --> vcs
  pip <-- Tor <-- here -- vcs


pip checks if the signature matches the public key and signature from pypa
pip -- give me public key --> keyserver
pip <-- PK -- keyserver
pip checks signature given by VCS against the sdist given by pypy
pip caches public key and repo location

1 설치된 소스는 서명 때문에 VCS의 소스와 일치합니다.
2 작성자도 일치
3 pypa는 새 사용자와 치팅을 할 수 있지만 치팅은 기존 사용자가 감지할 수 있습니다.
4 작성자는 pypy에 제공되지 않은 웹 인터페이스 분기에 표시하여 속임수를 사용하고 pypy에 다른 분기를 보낼 수 있습니다. 분기를 URI의 필수 부분으로 만들면 잘 작동하지 않습니다.

@KOLANICH pypy/pypa라고 할 때 PyPI(Python Packaging Index)를 의미한다고 생각합니다. PyPy는 Python의 대체 구현입니다. PyPA(Python Packaging Authority)는 Python Packaging 공간에서 주요 프로젝트를 유지 관리하는 자원 봉사자 그룹입니다. 두문자어를 올바르게 사용하거나 사용을 삼가해 주십시오.

기존의 잘 정립된 서비스의 디자인을 근본적으로 바꾸자는 제안을 하고 있습니다. 이러한 주요 변경 사항을 원할 경우 기존 워크플로의 전환을 허용/최소화하기 위해 아키텍처를 관리/변경하기 위해 최소한 (가능한) 전환 계획 및 POC 구현을 제공할 수 있습니다. 외부 호스팅에 의존하는 것은 PEP 470 의 과거 PyPI에서 명시적으로 제거된 것이지만 이는 귀하가 제안하는 것과는 상당히 다른 경우입니다.

PyPI는 기부/후원 인프라에서 실행되는 자원 봉사자에 의해 유지 관리됩니다. 다른 자원 봉사자 유지/실행 서비스인 Tor를 통해 연결하도록 제안하고 있습니다. 이 두 가지 모두 주요 프로젝트이며 사용자에게 직접적으로 표시되지 않거나 표시되지 않더라도 계속 실행하는 것과 관련된 비용이 있습니다.

그럼에도 불구하고 이것은 이 토론에 적합한 장소가 아닙니다. PyPI의 재설계를 제안하고 싶다면 https://github.com/pypa/warehouse 에서 토론을 다시 시작하는 것이 좋습니다

제안해 주셔서 감사합니다.

이것이 이후 릴리스로 푸시된 이유는 #5571 -- PR을 참조하십시오.

PIP 설치 로그의 경고는 이 URL을 제공하지만 여기나 언급된 다른 티켓에 문제에 대한 해결책이 없습니다.

게다가 이것은 훨씬 더 혼란스럽습니다. PyPI라고 하면 무엇을 의미합니까? PyPI 인터페이스(예: Artifactory)를 구현하는 서버를 의미합니까, 아니면 특히 pypi.org를 의미합니까?

이제 분명히 setuptools ( setup.py install 실행이라고도 함)를 통한 패키지 설치와 pip install 사용을 모두 지원하려는 사람은 이제 피클에 있게 될 것입니다. 종속성 링크를 지정하는 것은 이 상황에 있는 누군가가 여러 상호 종속성 패키지를 처리할 수 있는 유일한 방법입니다.

이제 내가 틀렸다면 정정해 주세요. 하지만 지금까지는 PyPA가 서버에 업로드하는 것과 관련하여 내린 결정에 따라 이것을 제거하면 기본적으로 Artifactory 사용자에게 pip 쓸모없게 만드는 것 같습니다. 상호 의존적인 패키지가 있는 개인 저장소가 있는 회사.

이 전체 이야기에서 내가 틀렸고 놓친 부분이 있다고 말해주세요. 저는 PEP 508을 빨간색으로 지정했지만 이 점에서 실제로는 아무런 차이가 없습니다. 적어도 상황을 더 좋게 만들거나 나쁘게 만들 수는 없습니다.

@wvxvw-traiana PR #5571을 놓친 것 같습니다.
그 이전에 PR(현재 릴리스에서 -- 18.0)은 PEP508 구문을 통해 지정된 종속성 설치를 거부합니다.

그 후 PR(이미 병합되었으므로 18.1+에 있어야 함) 후 pip는 종속된 패키지가 pypi.org에서 제공되는 경우에만 이러한 종속성을 거부합니다.

pypi의 항목에 의존하는 개인 저장소에서 패키지를 설치하면 분명히 괜찮습니다.
개인 저장소의 항목에 의존하는 pypi.org에서 패키지를 설치하면 실패합니다.
개인 저장소의 항목에 의존하는 개인 저장소의 패키지를 설치하면 괜찮습니다.

문제를 해결하는 데 도움이 되기를 바랍니다.

@bstrdsmkr 같은 출처입니까 아니면 pypi가 특별한 경우입니까? 즉

다른 개인 저장소의 항목에 의존하는 개인 저장소에서 패키지를 설치하는 경우.

이에 대한 이유에 대한 추가 컨텍스트를 추가하려면 다음을 수행합니다.

1. 직접 URL 링크를 사용하면 패키지가 인터넷 어디에서나 임의의 코드를 다운로드하고 실행할 수 있습니다. 당신이 패키지에 대한 책임을 지고 있다면 괜찮습니다. 그래서 우리는 그 이해에 대한 직접적인 URL 링크를 허용합니다.
2. 사람들은 PyPI(특히 일반적으로 패키지 인덱스가 아닌 PyPI)에서 설치하고 여기에서 다운로드하는 패키지를 신뢰하기를 기대합니다. 많은 수의 Python 사용자를 노출시키는 PyPI 패키지의 손상을 방지하기 위해 PyPI에서 오는 패키지가 직접 URL 링크에 의존하는 것을 허용하지 않습니다. 외부 코드에 대한 링크에 사용하는 PyPI에서).
3. 종속성 링크는 setuptools 관련 메커니즘이며 pip가 아닌 setuptools의 내부 기계에 의해 처리됩니다. 따라서 직접 URL 링크와 달리 우리는 링크가 수행 하는 작업을 제어할 수 없습니다. 이것이 우리가 우리가 직접 처리하는 표준 직접 URL 형식을 위해 사용하지 않는 이유입니다.

setuptools(setup.py install 실행이라고도 함)를 통한 패키지 설치와 pip install 사용을 모두 지원하려는 사람은 이제 피클에 있습니다.

true인 경우 setuptools가 합의된 표준인 직접 URL 링크에 대한 지원을 구현하지 않았기 때문입니다. 그들과 함께 그것을 높이십시오.

다른 개인 저장소의 항목에 의존하는 개인 저장소에서 패키지를 설치하는 경우.

잘 작동합니다. PyPI는 관련되지 않습니다.

좋습니다. 한편으로는 이것이 저에게 영향을 미치지 않아 기쁩니다.

다른 한편으로, 이 "수정"은 어떻게 하면... 해결하기가 너무 쉬운 것 같습니다.

echo "not-pypi 151.101.61.63" >> /etc/hosts
pip install --index-url not-pypi

내 비즈니스는 아니지만 실제로 표면 수준의 접근 방식처럼 보입니다. (다른 공격 벡터는 setup.py에서 원하는 것을 다운로드할 수 있는 다른 주석에서 언급되었습니다.)

사용자 가 https://github.com/pypa/pip/pull/4175#issuecomment -266305694를 참조

@dpwrussell pypi.org는 특별한 경우입니다. 모든 개인 저장소에 대한 모든 개인 저장소는 변경 후에 제대로 작동합니다.

@wvxvw-traiana 직접 하는 것을 방지하기 위한 것이 아닙니다. pypi.org에서 패키지를 설치하고 있다고 생각할 때 다른 사람이 당신에게 그렇게 하지 못하도록 하기 위한 것입니다.

현재 토론과 관련이 없지만 이에 대한 사용 중단 경고를 실제로 업데이트하지 않았기 때문에 다시 엽니다.

5726은 IMO가 이에 필요한 마지막 비트인 PEP 508 URL의 사용을 제안하는 언어를 추가합니다.

알겠습니다. 요약하자면:

• 종속성 링크는 여전히 사용되지 않으며 이제 pip 19.0에서 제거될 예정입니다.
• 이에 대한 표준 지원 대체는 PEP 508 URL 종속성입니다.
• PyPI에서 설치할 때 패키지에 PEP 508 URL 종속성이 있으면 pip가 설치를 중단합니다.

@pfmoore 는 여기에서 이러한 결정에 대한 이유를 자세히 설명했습니다. https://github.com/pypa/pip/issues/4187#issuecomment -415067034

@pradyunsg PEP 508 URL 종속성은 setup.py의 install_requires 에서 언제 허용됩니까? 날짜가 정해져 있나요?

pip의 다음 릴리스에서는 10월로 예정된 18.1입니다. https://pip.pypa.io/en/latest/development/release-process/에서 pip의 3개월 릴리스 주기에 대해 자세히 알아볼 수 있습니다. :)

PEP 508 URL 종속성이 실행 가능한 대안이 되기 전에 https://github.com/pypa/wheel/issues/249 를 해결해야 합니다.

PEP 508 URL 종속성이 실행 가능한 대안이 되기 전에 pypa/wheel#249 를 해결해야 합니다.

이 문제가 해결되었습니다.

pip 18.1 릴리스 노트에는 다음과 같이 나와 있습니다.

PEP 508 URL 요구 사항이 종속성으로 사용되도록 허용합니다.

보안 조치로, PyPI에서도 호스팅되지 않는 패키지에 패키지가 의존하는 경우 PyPI에서 패키지를 설치할 때 pip는 예외를 발생시킵니다. 앞으로 PyPI는 이러한 외부 URL 종속성이 있는 패키지를 직접 업로드하는 것을 차단할 것입니다. (#4187)

따라서 이것은 기본적으로 URL을 사용하여 종속성을 지정할 수 있음을 의미하지만 PyPI URL이 아닌 경우 pip를 사용하여 패키지를 설치할 수 없습니까? 내가 완전히 잘못 알고 있는 것일 수도 있지만 URL 종속성은 어떻게 사용되어야 합니까?

PyPI에서 호스팅되는 @JarnoRFB 패키지는 URL 종속성을 가질 수 없습니다.

PyPI에서 호스팅되지 않는 패키지는 URL 종속성을 가질 수 있습니다. 예를 들어 github에서 직접 패키지를 설치하면 url 종속성이 해결되고 설치됩니다. 그러한 설치의 예:

pip install git+https://github.com/bstrdsmkr/some_package.git

기본적으로 URL에서 설치하는 경우 URL에 의존할 수 있고 그렇지 않으면 그렇지 않습니다. 그리고 명확성을 위해 URL 및 비 URL 종속성을 모두 가질 수도 있습니다.

사소한 추가 사항:

...URL에서 설치하는 경우 URL에 따라 달라질 수 있습니다.

...URL(VCS 또는 기타)이나 로컬 파일 또는 PyPI가 아닌 패키지 인덱스에서 설치하는 경우...

위의 설명에 따라 install_requires를 처리하는 pip 버전이 있습니까? 최종 상태가 무엇인지 위의 태그를 해결할 수 없으며 현재 pip 문서는 여전히 dependency_links 를 사용하도록 말하는 setuptools의 install_requires 문서를 가리킵니다.

문서에 직접 말할 수는 없지만 PyPI가 아닌 패키지가 URL의 종속성을 설치할 수 있도록 하는 이 "휴식"은 pip 18.0에서 릴리스되었습니다.

AFAIK, install_requires의 URL 종속성은 pip 18.1부터 지원됩니다.

PEP 508 URL 요구 사항이 종속성으로 사용되도록 허용합니다.

출처: 릴리스 노트

어, 내 부분의 오타 -- @pietrodn 이 분명히 맞습니다.

나는 이 문제를 처음 접한 (나처럼) --process-dependency-links로 무엇을 해야 할지 겁을 먹은 사람들을 위해 작지만 성공적인 예를 여기에 남기고 싶습니다. 이 워크플로를 사용하여 내 사용자는 이제 GitHub 또는 로컬 소스(PyPI 아님)에서 pip 설치하거나, ​​requirements.txt를 설치하거나, ​​python setup.py install로 pip 설치하고, pip를 사용하여 Travis-CI에서 작업할 수 있습니다. 버전 18 이상이므로 많은 기반을 다룹니다. 누군가에게 유용하기를 바라며 이것이 다른 사람들에게 주제에서 벗어난 것처럼 보인다면 사과드립니다.

requirements.txt 파일에서 사람들이 패키지 "foo"의 GitHub dev 분기에 의존할 수 있기를 원한다고 가정합니다. 예:

scipy>=0.17
matplotlib>=2.0
foo @ git+https://github.com/foo-organization/foo@dev#egg=foo-9999

setup.py 파일에서:

import os, sys
from setuptools import setup, find_packages

def read_requirements():
    """Parse requirements from requirements.txt."""
    reqs_path = os.path.join('.', 'requirements.txt')
    with open(reqs_path, 'r') as f:
        requirements = [line.rstrip() for line in f]
    return requirements

setup(
    ..., # Other stuff here
    install_requires=read_requirements(),
    )

install_requires 와 requirements.txt 합치는 것은 바람직하지 않다고 말하는 사람도 있고, 릴리스 버전의 경우에는 동의하지만 개발용으로는 잘 맞는다고 생각합니다.

아, 깔끔하다. 따라서 패키지 "A"와 "B"가 모두 이 방법을 사용하고 패키지 "A"가 "B"를 종속성으로 나열하는 경우 "A"를 설치하려고 할 때 실제로 "B"에 대한 requirements.txt를 처리하게 됩니다. (보통은 그렇지 않습니다) - 맞습니까?

나는 또한 그 자체가 그 설치 수는 어떤 핍 옵션을 무시 의미 setuptools에 의해 이루어 졌기 때문에 좀 나쁜 install_requires 아침을 읽을 수 있지만 그 정보가 오래된 경우 나도 몰라 ...

나는 또한 오늘 아침에 install_requires 자체가 setuptools에 의해 수행되었기 때문에 다소 나빴다는 것을 읽었습니다. 즉, 모든 pip 옵션이 무시되었지만 해당 정보가 오래된 것인지 모르겠습니다...

install_requires 와 setup_requires 혼동하고 계십니다.

아, 깔끔하다. 따라서 패키지 "A"와 "B"가 모두 이 방법을 사용하고 패키지 "A"가 "B"를 종속성으로 나열하는 경우 "A"를 설치하려고 할 때 실제로 "B"에 대한 requirements.txt를 처리하게 됩니다. (보통은 그렇지 않습니다) - 맞습니까?

@stevebrasier 예, B가 아닌 A에 다른 필수 패키지의 다른 버전을 고정한 경우 문제가 될 수 있다고 생각합니다.

안녕하세요 여러분, 이 경우 사용 중단 경로가 너무 짧았다는 점을 말씀드리고 싶습니다. 나는 의존성 링크가 오랫동안 더 이상 사용되지 않는 것으로 표시되었다는 것을 알고 있지만 이를 대체하는 데 사용할 수 있는 PEP 508 URL은 18.1까지 구현되지 않았습니다. 결과적으로 종속성 링크에서 URL 요구 사항으로 전환하는 데 3개월이라는 긴 기간이 있었고 이는 대규모 프로젝트의 경우 매우 짧은 시간이었습니다.

@rgerkin 안녕하세요, 귀하의 지시를 따르려 하지만 소용이 없습니다.

PACKAGE@ git+ ssh://[email protected] :OWNER/PACKAGE를 검색합니다. git@BRANCH
https://pypi.org/simple/PACKAGE/ 읽기
'PACKAGE'에 대한 색인 페이지를 찾을 수 없습니다(철자가 잘못되었을 수 있습니까?)
모든 패키지의 인덱스 검색(시간이 걸릴 수 있음)
https://pypi.org/simple/ 읽기

패키지@ git+ ssh://[email protected] : 소유자/패키지. git@BRANCH , 이것은 install_requires에 있습니다.

내가 왜 위의 내용을 받는지 알 수 있겠습니까?

@KevinMars git_ssh, bitbucket, a.git 접미사, 명명된 분기 및 버전 태그 사용을 포함하여 제 예제와 귀하가 가지고 있는 것 사이에는 몇 가지 차이점이 있습니다. 아마도 이러한 것들 중 하나 이상이 pip가 URL 대신 PyPI에서 검색하도록 유도할 수 있습니다. 어떤 버전의 pip를 사용하고 있습니까?

내가 찾은 것이 무엇인가주의로 : 사용 setup.py 함께 패키지 설치 python setup.py install 여전히 외부 종속성의 선언이 필요합니다 dependency_links .

setup.py 파일에서:

import os, sys
from setuptools import setup, find_packages

def read_requirements():
    """Parse requirements from requirements.txt."""
    reqs_path = os.path.join('.', 'requirements.txt')
    with open(reqs_path, 'r') as f:
        requirements = [line.rstrip() for line in f]
    return requirements

setup(
    ..., # Other stuff here
    install_requires=read_requirements(),
    )

@rgerkin 이 솔루션을 공유해 주셔서 감사합니다. 하지만 pbr을 사용하여 Python 패키지를 설정하면 어떻게 될까요? 이것을 pbr에 맞게 조정하는 방법은 무엇입니까?

@KevinMars 똑같은 문제가 있습니다. 수정 사항을 파악한 적이 있습니까? SSH를 통해 개인 bitbucket 리포지토리의 특정 분기를 요구하려고 합니다.

방금 --process-dependency-links가 더 이상 존재하지 않는다는 것을 깨달았습니다. 커뮤니티가 하는 모든 일에 감사드립니다. 끝없는 토론과 미로 같은 문제 종결 및 리디렉션에서 결정을 정당화하는 것이 선택한 솔루션이지만 여전히 이 옵션을 떠나면 아무도 해를 끼치지 않을 것이라고 생각합니다.