흠, PyPI에서 사용 가능한 모든 패키지 버전을 나열하는 명령이 필요할 수도 있습니다.
어떻게 생각하세요?

처럼:

$ pip list Django

1.2.4

1.2.3

1.2.2

1.2.1

1.2

1.1.3

1.1.2

1.0.4

$

Original Comment By: Hugo Lopes Tavares

나는 그 아이디어를 좋아한다.

Original Comment By: CarlFK

방금 내 포크에 구현했습니다. 나는 carljm, jezdez 및 ianb의 의견을 원합니다
병합하기 전에.

여기에서 확인하십시오: https://bitbucket.org/hltbra/pip-list-
명령/변경 집합/e5c135a46204

Original Comment By: Hugo Lopes Tavares

깊이 생각해보진 않았지만 개선하는게 나을것 같습니다
버전을 나열하는 "search" 명령(-v 플래그를 사용하여 모든 버전을 나열할 수도 있음)
또는 무언가), 새로운 별도의 명령을 추가하는 대신. 이 기능
논리적으로 검색의 일부인 것 같습니다.

Original Comment By: Carl Meyer

다른 ER이 구현되어 있는 한 검색에 이것을 추가해도 괜찮을 것입니다.
django의 버전을 찾을 때 3000줄(실제로)이 나오지 않도록 합니다.
(모든 django-foo 때문에 "pip search django"에 1000개 이상의 조회수가 있습니다.
패키지. )

Original Comment By: CarlFK

나는 어떤 버전이 설치될 것인지 보여줄 필요가 없다고 생각한다.
사용 가능한 버전 목록이 있습니다.
이것은 최신입니다. 또한 새로운 플래그를 사용할 이유가 없습니다.
오버헤드가 0에 가까워지기 때문에 이 목록의 출력을 활성화합니다. 이것의
작은 변화:
https://bitbucket.org/jumpa/pip/changeset/62076643cf33

Original Comment By: jumpa

안녕하세요 Carl, 검색 명령에 옵션을 추가하는 방법에 대해 알고 있지만 두려움이
설치 명령에 무슨 일이 일어났는지: "업그레이드"하려는 경우
패키지를 사용하려면 "설치" 옵션을 사용해야 합니다. 이상하게도 우리는 알고 있습니다.

그리고 대부분의 사람들이 검색에 옵션을 추가하는 것이 더 낫다고 생각하더라도
search --versions 또는 search -v 사용에 대한 많은 문제.

Original Comment By: Hugo Lopes Tavares

기본적으로 사용 가능한 모든 버전을 나열하는 것은 너무 장황합니다. 일부
패키지에는 pypi에서 사용 가능한 버전이 많이 있습니다. 10 또는 20은 드문 일이 아닙니다.
조금도. 기본적으로 최신 버전 및 플래그가 있는 모든 버전 나열
합리적인 것 같습니다.

그리고 검색을 위해 개선이 필요하다는 CarlFK에 동의합니다.
좁히기 쉽습니다. 문제는 PyPI의 API가 제공하는 것에 의존한다는 것입니다.
그다지 많지는 않습니다. 우리는 PyPI를 모두 다운로드하지 않고 정규식을 수행하지 않을 것입니다.
현지에서 검색! 검색할 --exact 플래그와 같은 것을 선호합니다.
이 변경 사항의 일부이므로 예를 들어 "--exact django"를 검색하고
결과에 django 자체가 표시됩니다.

Original Comment By: Carl Meyer

안녕하세요 jumpa, xmlrpc에서 가져온 버전을 사용하여 버전을 표시하는 좋은 아이디어입니다.
연결!

pip를 검색하는 다음 스니펫이 있습니다.

pip                       - pip installs packages.  Python packages.  An

easy_install 교체(버전: 0.2, 0.2.1, 0.3, 0.3.1, 0.4, 0.5, 0.5.1,
0.6, 0.6.1, 0.6.2, 0.6.3, 0.7, 0.7.1, 0.7.2, 0.8, 0.8.1, 0.8.2)

이것은 많은 버전을 사용하는 매우 큰 패키지 목록이 될 것입니다.
검색은 이름과 요약을 중요하게 생각하기 때문입니다. 우리가 그것에 대해 관심을 가져야 합니까?

Original Comment By: Hugo Lopes Tavares

최종 사용자로서 나는 별도의 목록 명령*이 있다는 아이디어를 좋아합니다. 시간에
별도의 명령을 사용하면 분리하여 수정하고 향상시키는 것이 더 쉬울 수 있습니다. 에게
별도의 list 명령을 더 유용하게 만들면 어떤 버전인지 나타낼 수 있습니다.
현재 설치되어 있습니다.

pip list Django


1.2.4

1.2.3 installed

1.2.2

1.2.1

1.2

1.1.3

1.1.2

1.0.4

참고: YUM(RedHat), pkglist(BSD),
dpkg(Debain)는 별도의 목록 플래그 또는 명령을 제공합니다.

Original Comment By: Kelsey Hightower

Carl, 나는 이 문제에 대해 다른 날 생각하고 있었는데,
Kelsey: 다른 명령은 나쁘지 않습니다.

플래그를 사용하여 해당 패키지 이름만 원한다는 것을 표시하고
사용 가능한 모든 버전을 검색하고 싶습니다.

조금 이상하다.

예를 들어 보겠습니다.

$ pip search -v --exact Django

~ 대

$ pip list Django

설치된 버전을 보여주는 Kelsey의 아이디어는 목록을 향상시킵니다.
명령.

Original Comment By: Hugo Lopes Tavares

검색 명령을 변경했습니다.

검색 명령은 이미 설치된 버전과 사용 가능한 최신 버전을 표시하므로 검색 명령을 보강하여 사용 가능한 모든 버전도 나열하는 것이 더 합리적일 수 있습니다.

내 변경 세트는 다음과 같습니다. https://github.com/phuihock/pip/commit/46bad23b5bf31850a02803ea1ca18be5deca9db3

이 상태는 어떻습니까? pip를 사용하여 PyPI에서 사용 가능한 최신 버전을 볼 수 있습니까?

이것은 이미 구현되어 있습니까? 이것은 약 2년 동안 저를 괴롭히고 있으며, 이 문제가 해결되기를 바랍니다.
버전 플래그와 결합된 제한된 검색은 매우 유용한 솔루션처럼 보입니다.

버전을 표시하는 방법을 검색하는 동안 이 스레드를 건너뛰었다는 것을 여기에 추가하고 싶었습니다. pip search -v package를 시도했습니다. 버전 정보를 포함하여 설치해야 합니다...

나는 _그냥_ 이 기능이 내 동료가 나에게 물어본 후에 이 기능이 아직 구현되지 않았다는 것을 깨달았습니다. 다음 버전의 pip 에서 사용할 수 있게 될 계획이 있습니까?

이 PR 이 관련이 있을 수 있다고 생각합니다. 현재 작업 중인가요?

또한 Linuxconf 2014 강연 "Python Packaging 2.0: Playing Well With Others" 에서 파이썬 패키징의 현재 상황과 미래에 대해 관심을 가질 수도 있습니다. 발표자는 (내가 올바르게 이해했다면) pip의 메타데이터에 대한 일부 제한 사항은 원래 CPAN을 기반으로 하는 PyPI 설계의 결과이며 PyPI의 백엔드를 재작업한다고 말했습니다(테스트를 사용하는 현재 백엔드와 호환 가능함) 상황을 개선해야 합니다. 그는 주로 "시스템 통합자", 즉 다운스트림 패키징에 대해 이야기하고 있었지만, 그것이 이 문제와 같은 문제에 영향을 미치므로 문제를 더 쉽게 해결할 수 있을 것이라고 생각합니다.

+1,000,000

지금은 어때?

이제 설치하지 않고 최신 버전을 표시하는 방법이 있습니까?
이 문제는 2011년부터 열려 있습니다. 위에서 본 패치는 한 줄에 불과합니다. :(

이것은 활성화할 수 있는 사소한 기능인 것 같습니다. 어떻게 이 시점에서 apt-cache madison 에 해당하는 옵션이 없을까요?

검색할 때도 최신 버전의 PyPi 패키지를 보고 싶습니다. 정확히 일치하면 작동하지만 해결 방법으로 awk를 사용합니다.

이것은 저를 좌절시켰고 이것에 대한 희망이 거의 또는 전혀 없다는 것을 알고 대안을 만드는 것이 시간을 할애할 가치가 있다고 결정했습니다. 이 문제와 함께 다른 요청된 기능(예: 정규식 검색 및 색상 출력 등)을 구현했습니다. 관심이 있으시면 여기에서 확인할 수 있습니다

wget -qO- https://pypi.python.org/pypi/uWSGI | egrep -o "uwsgi-[0-9].[0-9].[0-9][0-9].tar.gz" | 정렬 -u

wget -qO- https://pypi.python.org/pypi/uWSGI/json | grep '"version"'

@andreif 이것은 항상 올바른 버전을 찾지 않습니다(--pre가 제공되지 않는 한 pip는 알파, 베타, 릴리스 후보 등을 무시합니다). 이것은 더 가깝습니다(그러나 보장도 없음):
wget -qO- https://pypi.python.org/pypi/uWSGI/json | grep -E ' {8}"[0-9."]*": \[' | sort -V | tail -n 1 | tr -d ' ":['

좋습니다. 그러면 JSON 응답에 "pre-version": "1.2.3a4" 와 같은 항목이 포함되어야 하므로 간단한 표현식으로 둘 다 grep할 수 있습니다.

이 문제가 정말 이해가 안 가요... 이게 무슨 일이죠?

• pip install 에 새 옵션을 추가하면 패키지가 해결될 때까지만 pip가 실행되고 선택한 패키지가 인쇄되고 종료됩니다(설치 건너뛰기)?
• pip search 를 사용할 때 패키지 이름 옆에 최신 버전을 표시합니까?
  
  
  
  • PyPI에서 최신 버전의 패키지를 볼 수 있습니까?
  
  

후자는 나에게 해결된 것 같고 전자는 아마도 새로운 전용 문제가 있어야 합니다.

@pradyunsg 글쎄요, 제 기억이 맞다면 현재 사용 가능한 버전(출시 및 시험판 모두)을 확인할 수 있는 간단한 방법이 필요했습니다. 이 버전은 pip install -U [--pre] 에 의해 설치됩니다.

virtualenv를 설정하는 스크립트에 필요했습니다. 최신 버전의 패키지가 있을 때 현재 버전을 업데이트할지 아니면 유지할지 묻습니다. 따라서 이 사용 사례는 새로운 pip 검색에 포함됩니다.

pkg="foo"; pip install --download /dev/null --no-cache-dir --no-binary :all: "$pkg" 2>&1 | egrep -i "$pkg"'-' | head -1 | egrep -io "$pkg"'-[^ ]+' | sed 's/^'"$pkg"'-\(.*\)\.tar\.gz$/\1/g'

--download 게시 - 지원 중단 버전...

pkg="foo"; tmp="$(mktemp -d)"; pip download -d "$tmp" --no-cache-dir --no-binary :all: "$pkg" 2>&1 | egrep -i "$pkg"'-' | head -1 | egrep -io "$pkg"'-[^ ]+' | tr A-Z a-z | sed 's/^'"$pkg"'-\(.*\)\.tar\.gz$/\1/g'

다음과 같은 것을 사용합니다.

pip install foo==

사용 가능한 모든 버전 목록을 제공합니다(유효한 pypi 사용 가능한 패키지의 경우 이 경우 분자).

Could not find a version that satisfies the requirement molecule== (from versions: 1.20.1, 1.20.3, 1.21.1, 1.22.0, 1.23.0, 1.25.0, 1.25.1, 2.10.0, 2.10.1, 2.11.0, 2.12.0, 2.12.1, 2.13.0, 2.13.1, 2.14.0, 2.15.0, 2.16.0, 2.17.0, 2.18.0, 2.18.1, 2.19.0) No matching distribution found for molecule==

그러나 실제로 다운로드 및/또는 dev/null에 설치하지 않고 pip를 사용하여 설치할 버전을 얻을 수 있다면 좋을 것입니다 :-)

동의. 이 기능이 없는 패키지 관리자는 일종의 농담입니다. 버전 목록을 가져오는 예제조차도 이 패키지 관리자에 없는 또 다른 기능을 보완하기 위한 완전한 해킹입니다. 내가 그것을 의미하는 것은 아니지만, 이것들은 완전히 무시되는 바로 이 버그가 생성되기 훨씬 전에 8년 전에 사용 가능했어야 하는 것들입니다. 나는 pip가 실제로 더 많은 기능을 가지고 있지만 또한 가증스럽고 기괴하고 엄청나게 크고 지나치게 복잡한 것으로 대체될 것이라고 가정합니다. 글쎄, 우리는 항상 우리 자신의 것을 쓸 수 있습니다.

pip-tools는 pip를 기반으로 하는 도구로 이 스레드의 사람들이 질문하는 몇 가지 사항에 도움이 될 수 있습니다. https://github.com/jazzband/pip-tools

추상 종속성 목록을 제공하면(즉, 버전이 지정되지 않음) 설치할 각 요구 사항 및 종속성의 특정 버전을 알려줍니다.

pkg="django"; echo "$pkg" | pip-compile - --output-file - | egrep -i '^'"$pkg"'=' | cut -d '=' -f 3- 는 거의 어리석은 것입니다(설치해야 하는 또 다른 것으로 계산하면 더 어리석음[python2 지원이 필요한 경우 더 어리석음])

게다가 pip-tools(& pipenv)의 요점은 일반 pip와 제약 파일로 수행할 수 있습니다. ( pip install -r reqs -c constraints; pip freeze > constraints ).

pip install 에 새 옵션을 추가하면 패키지가 해결될 때까지만 pip가 실행되고 선택한 패키지가 인쇄되고 종료됩니다(설치 건너뛰기)?

방금 여기에서 몇 가지 중요한 하우스키핑을 수행했으며 이 문제는 이제 이 사용 사례를 추적/토론하기 위한 것입니다. 새로운 기능에 대한 이 요청을 수용하기 위해 pip가 변경되는 경우/방법입니다.

관련 컨텍스트가 더 이상 첨부되지 않은 정말 오래된 댓글부터 "잠재적인 해킹/스크립팅 덩어리"가 포함된 댓글에 이르기까지 전체 작업의 90%를 수행하는 댓글에 이르기까지 많은 댓글을 숨겼습니다. 후자 그룹의 경우 여기에 후자를 더 게시하지 마십시오. 도구 자체에서 수정 사항을 구현하는 방법을 논의하는 포럼이 아니라 이러한 제안이 더 적절한 다른 사용자 지원 포럼이 있습니다. :)

실제로 여전히 관련성이 있고 유용한 댓글이 숨겨져 있는 사람에게 사과드립니다. 많은 댓글에 대한 맥락을 파악할 수 없었고 귀하의 댓글이 부수적 피해에 숨겨져 있었을 수도 있습니다.

이 티켓은 종속성 해결 프로그램(#988)의 개발로 인해 차단되었기 때문에 팀이 해당 주제에 대해 앞으로 나아가기 위해 커뮤니티의 도움을 찾고 있다고 여기에서 언급하고 싶습니다.

우리는 새로운 리졸버가 실패하는 상황을 더 잘 이해해야 하므로 복잡한 종속성을 가진 pip 사용자에게 다음을 요청합니다.

1. 새로운 리졸버를 사용해보십시오(버전 20.1 사용, --unstable-feature=resolver 실행)
2. 깨세요 :P
3. 문제 제기

여기에서 더 많은 정보와 자세한 지침 을 찾을 수 있습니다.

이 스레드에서 아직 언급하지 않은 #7819의 실험에서 발생했음을 강조하고 싶은 한 가지 사용 사례는 위에서 논의한 잠금 파일과 약간 직교하는 기능인 나중에 패키지를 다운로드하고 설치하기 위한 URL을 기록 하는 것입니다. 큰 파일을 다운로드할 필요 없이 pip resolve의 결과를 사용하는 데 특히 유용합니다.

우리는 Twitter에서 일반적으로 기계 학습 응용 프로그램이 처음 실행될 때까지 타사 코드를 포함하지 않고 배송될 수 있는 "ipex"라고 부르는 기계 학습 응용 프로그램의 패키징 방법을 개발해 왔습니다(크기를 크게 줄임). pantbuild/pants#8793의 경우 요구 사항을 해결하기 위해 pex 런타임 라이브러리를 호출하는 실행 가능한 pex 아카이브를 생성합니다(pex는 덮개 아래에서 pip를 실행합니다). 저는 현재 런타임 시 전체 pex/pip 확인 단계를 dist를 다운로드할 URL만 기록하는 교체로 대체하는 프로토타입을 작업 중입니다( req.link ). 이것은 "수화된" pex 파일을 생성하기 위한 다운로드 및 파일 복사가 완전히 병렬로 수행될 수 있기 때문에 실제로 매우 빠릅니다(매우 세부적으로 캐시될 수 있음).

그 기능(수톤의 바퀴/비 바퀴를 병렬로 다운로드 및 설치)은 추가로 잠금 파일에 넣을 바퀴 또는 바퀴가 아닌 URL을 노출하는 데 의존합니다. 여기에는 아직 언급되지 않았습니다. 이를 통해 바지는 탈수된 ipex 파일이 생성될 때 pip를 정확히 한 번(다운로드 URL을 해결하기 위해) 호출할 수 있으며, URL이 포함된 해당 "해결" 단계의 결과는 ipex 파일이 완전히 처음 호출될 때 요구 사항을 다운로드하는 데 사용될 수 있습니다. pip를 다시 호출할 필요 없이 다른 시스템에서 사용할 수 있습니다.

v1 리졸버의 내장에서 출력으로 URL을 전파하려면 #7819에서 많은 노력이 필요했습니다. v2 리졸버와 함께 작동하도록 마지막으로 시도했을 때 훨씬 적은 노력이었습니다. 지금 당장은 다운로드 URL을 내보내는 --dry-run 또는 resolve 명령의 일부 실험 버전을 내부적으로 출시할 계획입니다. 성공적으로 수행하면 모든 그 동안 --unstable-feature=resolver 에 대한 나머지 문제! :D :D

언급했듯이 잠금 파일 형식 디자인은 리졸버 구현과 직교합니다. 그러나 이는 현재 pip 프로젝트의 범위를 벗어남을 의미하기도 합니다. 이 주제에 대한 논의 가 있었습니다(경고: 매우 긴 스레드). 그러나 가용한 개발자 시간이 부족하다는 점을 고려하면 이는 결국 리졸버가 적어도 안정화되기 전에 진지한 논의가 일어나지 않을 가능성이 있음을 의미합니다.

링크 감사합니다!!

2020년 5월 24일 일요일 19:34 Tzu-ping Chung 알림 @github.com
썼다:

언급했듯이 잠금 파일 형식 디자인은
리졸버 구현. 그러나 그것은 또한 그것이 적용 범위를 벗어남을 의미합니다.
현재 핍 프로젝트. 주제에 대한 토론이 있었습니다
https://discuss.python.org/t/structured-exchangeable-lock-file-format-requirements-txt-2-0/876/1
(경고: 쓰레드가 매우 길다), 하지만 개발자 시간이 부족하다는 점을 고려하면
사용할 수 있는 경우 진지한 토론이 이루어지지 않을 가능성이
리졸버가 적어도 안정화되기 전에 발생합니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/pypa/pip/issues/53#issuecomment-633346918 또는
구독 취소
https://github.com/notifications/unsubscribe-auth/AAJ6UT3IK65CUQGUIOGBNVDRTHKMVANCNFSM4AIQRXLA
.

@cosmicexplorer --dry-run 또는 resolve 명령의 실험 버전을 아직 내부적으로 출하했습니까? 그렇다면 어떻게 진행되고 있습니까?

제가 이 기능에 매우 관심이 있다는 것을 눈치채셨을 것입니다 😄

다음과 같은 것을 사용합니다.

pip install foo==

사용 가능한 모든 버전 목록을 제공합니다(유효한 pypi 사용 가능한 패키지의 경우 이 경우 분자).

Could not find a version that satisfies the requirement molecule== (from versions: 1.20.1, 1.20.3, 1.21.1, 1.22.0, 1.23.0, 1.25.0, 1.25.1, 2.10.0, 2.10.1, 2.11.0, 2.12.0, 2.12.1, 2.13.0, 2.13.1, 2.14.0, 2.15.0, 2.16.0, 2.17.0, 2.18.0, 2.18.1, 2.19.0) No matching distribution found for molecule==

그러나 실제로 다운로드 및/또는 dev/null에 설치하지 않고 pip를 사용하여 설치할 버전을 얻을 수 있다면 좋을 것입니다 :-)

좋은 트릭 !! 유용하고 편리합니다!! 정말 인상적입니다!!

잠재적인 해킹/스크립팅 덩어리 ... 여기에 후자를 더 게시하지 마십시오. 도구 자체에서 수정 사항을 구현하는 방법을 논의하는 포럼이 아니라 이러한 제안이 더 적절한 다른 사용자 지원 포럼이 있습니다. :)

아무 것도 아닌 것은 아니지만 이것은 버그가 매우 오랫동안 남아있을 때 발생하는 종류의 일입니다(가장 최근에 기여한 "nugget"의 경우 7.56년, 이 아직 열려 있는 버그는 현재 9.25년입니다. 낡은). 사람들은 해결 방법을 공유합니다.

나는 또한 대안을 포함하여 댓글을 숨기는 것이 사람들이 댓글에 게시하려는 해결 방법이 불필요하다는 것을 깨닫는 데 도움이 될지 의심합니다(부분적으로는 아무도 이미 말한 내용을 보기 위해 숨겨진 댓글을 모두 클릭하지 않을 것이기 때문입니다). 누군가가 10년 된 버그에 도달하고 유지 관리자로부터 어떤 종류의 진전이나 방향 또는 해결 방법을 찾지 못하면 감히 그들이 필요한 해결 방법을 공유하는 것을 고려할 것입니다. 이미 수행한 자체는 불필요합니다.

그리고 네, 바로 이 코멘트는 아직 열려 있는 이 버그에 대한 응답으로 수행한 작업이 발생했을 때 발생하는 것이기도 합니다.

걱정하지 마십시오. pip가 내 스크립트를 다시 중단하고 이 버그가 여전히 열려 있지 않는 한 더 이상 도발되지 않은 주석을 추가하지 않을 것입니다.

해주셔서 감사합니다. :)

@brainwane @ei8fdb 이 문제를 UX 관점에서 중요한 것으로 플래그 지정하고 싶습니다 - #8377 관련

내 이해를 기반으로 한 높은 수준 요약:

• 새로운 리졸버를 사용하면 pip가 덜 관대해지고 충돌하는 종속성 설치를 거부합니다( ResolutionImpossible ).
• 종속성 충돌은 종속성 트리의 모든 위치에 존재할 수 있습니다.
• 기존 도구(pipdeptree pip-conflict-checker)는 요청되었지만 실패한 패키지가 아닌 이미 설치된 패키지만 표시합니다.
• 현재 사용자는 패키지가 설치되기 _전_ 어디에서 종속성 충돌이 발생했는지 또는 ResolutionImpossible 오류가 발생했을 때 해결할 수 있는 방법이 없습니다(각 프로젝트의 종속성을 수동으로 검사하는 것 외에는).

간단히 말해서 사용자가 최상위 요구 사항(예: requirements.txt 에 지정되거나 명령줄에 직접 입력되는 패키지)에 따라 가능한 종속성 충돌을 감지할 수 있는 방법이 필요합니다.

이렇게 하기로 결정하면 제안된 플래그 이름( --dry-run )을 조사/토론해야 합니다.

@uranusjr @pfmoore - 내가 잘못 알고 있는 것이 있거나 토론을 기반으로 놓친 부분이 있으면 수정해 주세요. 고마워

@nlhkabu 위의 모든 의견에 동의합니다. 그러나 분명히 하기 위해 --dry-run 스타일의 명령을 사용하면 사용자가 종속성 충돌이 있는지 확인할 수 있습니다. 그러나 설명된 대로 충돌이 존재하는 이유 를 진단하는 데 추가 도움을 제공하지 않습니다. 그래서 우리가 할 수 있으면 설치하지만, 그렇지 않으면 아무 것도 하지 않고 오류를 보고하는 일반적인 "용서 요청" 접근 방식과 대조적으로 기본적으로 "뛰기 전에 살펴보기" 설치 명령입니다.

이것이 제공하지 않고 IMO가 매우 유용할 수 있는 것(pip 하위 명령으로 또는 타사 도구만큼 유용함)은 pip가 작동하는 종속성 트리를 나열하는 방법입니다. . (이것은 리졸버나 실제 설치 단계가 필요하지 않으며 패키지 소스의 종속성 메타데이터를 "단순히" 나열하는 것입니다.)

이것은 pip resolve 명령의 형태를 취할 수도 있습니다.

pip resolve 는 대부분의 사람들이 기대하는 것입니다. 😄 결국 자체 플래그도 허용할 것입니다.

@pfmoore에 대한 설명 감사합니다. 사용자 관점에서 resolve --dry-run 가 얼마나 사용되는지 잘 모르겠습니다.

IMO, 사용자에게 오류가 발생할 것이라고 말하는 것만으로는 충분하지 않습니다. 또한 오류가 있는 위치를 찾고 이에 대해 조치 를 취하기에 충분한 정보를 제공해야 합니다.

따라서 사용자가 --dry-run 를 실행한다고 상상해보십시오. 응답에 다음과 같은 것을 포함할 수 있습니다.

종속성 충돌이 감지되었습니다. pip는 d 1.0 및 c 1.0을 설치할 수 없습니다.
충돌은 다음으로 인해 발생합니다.
d 1.0은 E==2.0에 따라 다릅니다.
c 1.0은 E==1.0에 의존
pip resolve 를 실행하여 종속성 트리를 검사합니다.

ResolutionImpossible 오류 메시지에서 pip resolve 를 재사용할 수도 있습니다(#8377 참조). 이는 큰 승리가 될 것입니다.

@pradyunsg pip resolve 티켓이 따로 있나요?

@nlhkabu https://github.com/pypa/pip/issues/7819

또한 명확하게 하기 위해 pip resolve 의 의도된 사용 사례는 다음 중 하나라고 생각합니다(성공을 가정).

1. 출력을 파일(일반적으로 커밋됨)로 리디렉션하거나
2. 다른 도구는 출력을 사용/분석합니다.

트위터의 경우 #7819에 설명된 "ipex" 도구를 사용하여 pip resolve 명령을 사용하여 실행 가능한 pex 파일을 만들고 있습니다. 이 명령은 아무 것도 다운로드하지 않고 확인된 모든 배포에 대한 다운로드 URL을 출력합니다(아직 프로덕션에서 사용되지 않음 ). 이것은 #8448과 같은 몇 가지 다른 최적화와 함께 몇 초 안에 이러한 ipex 파일을 생성할 수 있습니다. 그런 다음 이러한 ipex 파일은 동일한 데이터 센터 내에서 처음 실행될 때 pip resolve 명령의 모든 배포 출력을 다운로드합니다. 이렇게 하면 ipex 파일 자체가 기가바이트가 아닌 메가바이트가 되어 업로드 시간이 향상됩니다. 많은 지역에서.

그래서 우리는 기본적으로 pip resolve 출력의 json 버전을 pex 아카이브에 파일로 포함하고 부트스트랩 스크립트를 읽어서 배포판을 병렬로 다운로드합니다.

이에 대한 업데이트가 있습니까?

누군가는 먼저 해결 결과를 제시하는 방법을 알아낼 필요가 있습니다. 리졸버 작업에 관련된 AFAIK pip 유지 관리자는 현재 현재 리졸버 자체를 개선하기 위해 노력하고 있으므로 앞으로 나아가려면 외부의 도움이 필요합니다.

내가 틀렸다면 정정해 주시기 바랍니다. 그러나 다음은 사실인 것 같습니다.

• Python 패키지 설치에는 setup.py 실행이 포함됩니다.
• --dry-run 옵션이 없으면 pip의 리졸버가 설치할 패키지를 쉽고 안정적으로 알 수 없습니다.

따라서 pip install 를 실행한다는 것은 쉽고 안정적인 감사 방법 없이 컴퓨터에서 임의의 PyPI 패키지를 선택하여 코드를 실행하는 데 동의한다는 의미인 것 같습니다. 해당 선택은 개별 패키지 작성자의 종속성 선택 및 보안 방식에 따라 재귀적으로 달라집니다.

설치할 프로젝트와 버전이 소스 배포판(sdist, setup.py 포함) 또는 휠(빌드 배포판, 메타데이터 텍스트 파일 포함, 임의의 코드 실행 없이 파일 복사본으로 설치됨)만 포함하는지 여부에 따라 다릅니다.

--dry-run을 사용하더라도 pip는 바퀴가 없는 패키지(setuptools의 경우 setup.py 실행 포함)에 대한 빌드 백엔드를 실행해야 할 가능성이 높습니다.