Pipenv: 잠금이 느림(중복 다운로드 수행)

@colllin pip search 와 같이 서버에 접속하는 pip 명령어도 느린지 확인하셨나요?

비슷한 동작이 보이지만 알려진 문제이며 네트워크에 따라 다릅니다. 어떤 이유로 직장 네트워크에서 pypi.org에 액세스하는 것은 엄청나게 느리지만 일반적으로 홈 네트워크에서는 빠릅니다. 잠금은 내부적으로 많은 pip 트랜잭션을 수행하므로 서버에 대한 느린 액세스가 작업을 많이 느리게 한다고 생각합니다.

편집: 해결해야 할 하위 종속성이 많을 수도 있습니다. 한 번 생성된 환경의 크기(예: pipfile의 최상위 패키지 수 및 pip list 반환된 패키지 수) 환경이 부트스트랩되면)?

사려깊은 답변 감사합니다.

pip search 는 특별히 빠르거나 느리지 않습니다... ~1초?

도메인 지식이 부족한 저를 용서해 주십시오. PIP 검색이 정말로 필요한가요? 그냥 다 설치한거 아님? 이미 설치되어 있는 것을 기록하기만 하면 되는 것 아닌가요? 또는 ... 어쨌든 잠금 파일의 존재를 보장하기 때문에 패키지를 설치할 때 또는 이전에 이것을 할 수 있습니까?

내 생각에 ... pipenv는 후드 아래에서 pip를 사용합니까? 그래서 설치 프로세스는 블랙박스이고 ~pip search~ 자체 pip 쿼리를 수행하지 않고 무엇이 설치되었는지/설치될 것인지에 대한 종속성 그래프를 알 수 없습니까?

편집: 이 특정 리포지토리에는 1개의 최상위 패키지와 pip list 에서 반환된 ~65개의 패키지가 있습니다.

나는 프로젝트에 기여한 사람이 아니며 현재로서는 모든 세부 사항을 알지 못하지만 잠금 단계는 모든 종속성이 해결되고 고정되는 단계라는 것입니다. 따라서 ~65개의 종속성이 있는 최상위 패키지가 하나 있는 경우 잠금 단계 동안 해당 첫 번째 패키지의 모든 종속성이 (재귀적으로) 발견되고 종속성 트리를 사용하여 설치해야 하는 패키지를 확인하고 (아마도) 대략적인 순서로 설치해야 합니다. 마지막 부분은 확실하지 않습니다.

잠금 파일이 없는 Pipfile에서 pip install하면 패키지를 venv에 설치 하기 전에 잠금 단계 --deploy 것으로, 빠른 것 옵션을 --no-lock 옵션; 전자의 경우 잠금 파일이 오래된 경우 오류가 발생하고 후자의 경우 최상위 패키지(선언된 환경)와 모든 패키지의 실제 설치된(잠긴) 환경의 논리적 분할을 잃게 됩니다. 적어도 이것이 내가 이해하는 방식입니다.

pipenv가 후드 아래에서 pip를 사용하는지 여부 - 그렇게 생각합니다 - 여전히 pypi 서버에서 패키지 종속성 등에 대한 정보를 가져와야 하므로 pip 검색에 대한 내 질문은 얼마나 빠르거나 pypi 서버로 가는 경로를 느리게 하는 것은 pipenv가 그 일을 하는 메커니즘에 대한 직접적인 암시보다 더 많습니다.

흥미로운 실험은 pipenv에서 종속성 트리를 잠그고 pip install -r requirements.txt 사용하여 새 환경에 요구 사항을 설치하는 데 필요한 시간을 비교하는 것입니다. 나는 그들이 의존성 해결 단계에서 꽤 비슷한 일을 해야 한다고 생각합니다.

중복 다운로드가 발생한다는 것을 어딘가에 설정했습니까? 나는 그것이 사실이라고 생각하지만 그것을 증명하면 정말 도움이 될 것입니다.

참고로 pip install -r requirements.txt 를 종속성 그래프를 잠그는 데 걸리는 시간과 비교하는 것은 비교 포인트로 유용하지 않을 것입니다. Pip은 실제 의미에서가 아니라 실제로 리졸버를 _가져 있지_ 않습니다. 차이점을 설명할 수 있을 것 같습니다. pip가 requirements.txt 설치할 때 다음 기본 프로세스를 따릅니다.

• 나열된 첫 번째 요구 사항 찾기
  
  
  
  • 모든 종속성 찾기
  
  
  • 모두 설치
  
  
• 나열된 두 번째 요구 사항 찾기
  
  
  
  • 모든 종속성 찾기
  
  
  • 모두 설치
  
  
• 나열된 세 번째 요구 사항 찾기
  
  
  
  • 모든 종속성 찾기
  
  
  • 모두 설치
  
  

이것은 _package 1_의 종속성이 _package 3_의 종속성과 충돌하는지 여부를 pip가 실제로 신경 쓰지 않기 때문에 꽤 빠른 것으로 나타났습니다.

Pipenv는 다른 프로세스를 따릅니다. 환경을 구축하기 전에 지정한 종속성의 _모든_을 충족시키려는 해상도 그래프를 계산합니다. 이는 우리가 실제 설치 프로세스를 시작하기도 전에 여러분의 환경이 궁극적으로 어떤 모습이어야 하는지를 결정하기 위해 다운로드, 비교 및 ​​종종 _building_ 패키지를 시작해야 한다는 것을 의미합니다(왜 이것이 파이썬의 경우이므로 여기에서 더 자세히 다루지 않겠습니다).

해당 해결 프로세스의 각 단계는 해시를 요구하므로 계산 비용이 더 많이 듭니다. 이는 모범 사례입니다. 우리는 들어오는 패키지를 받은 후 해시하고 PyPI가 예상해야 한다고 말한 해시와 비교하고 해당 해시를 잠금 파일에 저장하여 미래에 동일한 환경을 구축하려는 사람들이 할 수 있도록 합니다. 패키지를 빌드하는 데 사용된 패키지가 원래 사용했던 것과 동일한 패키지임을 계약상 보장합니다.

Pip 검색은 이것에 대한 빈약한 벤치마크입니다. 사실 pip의 도구는 이 작업을 수행하기 위한 빈약한 벤치마크입니다. 우리는 각 부분에 대해 pip를 사용하지만 함께 구성하고 관리하기 위해 많은 종속성을 함께 사용합니다. 환경 및 그래프는 pipenv의 값이 추가되는 곳입니다.

한 가지 명확히 할 점은 전체 종속성 그래프를 해결하면 설치 순서가 더 이상 중요하지 않다는 것입니다. 후드 아래에서 우리는 실제로 --no-deps 를 모든 설치에 전달합니다.

작은 부수적으로, pip 검색은 현재 사용되지 않는 XMLRPC 인터페이스에 의존하는 유일한 pip 도구입니다. 이 인터페이스는 캐시할 수 없고 매우 느립니다. 다른 작업보다 항상 느립니다.

내 컴퓨터에서 numpy를 잠그는 데(다른 것은 아무것도 없음) 220초가 걸립니다(아래 참조). 대부분의 시간은 200MB 이상의 데이터를 다운로드하는 데 소비되는 것 같습니다. 이는 전체 numpy 소스에 4MB가 있다는 점을 감안할 때 상당히 당혹스럽습니다. 비록 그것이 즉각적일지라도, 여전히 25초의 실제 처리가 있고, 그마저도 몇 개의 해시를 계산하기에는 과도해 보입니다. Pipenv.lock을 삭제한 후에도 후속 잠금에는 5초가 걸립니다.

11:46 ~/Co/Ce/torchdft time pipenv install
Creating a virtualenv for this project…
Using /usr/local/Cellar/pipenv/2018.5.18/libexec/bin/python3.6 (3.6.5) to create virtualenv…
⠋Already using interpreter /usr/local/Cellar/pipenv/2018.5.18/libexec/bin/python3.6
Using real prefix '/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6'
New python executable in /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t/bin/python3.6
Also creating executable in /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t/bin/python
Installing setuptools, pip, wheel...done.

Virtualenv location: /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t
Creating a Pipfile for this project…
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (ca72e7)!
Installing dependencies from Pipfile.lock (ca72e7)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 0/0 — 00:00:00
To activate this project's virtualenv, run the following:
 $ pipenv shell
        7.81 real         6.39 user         1.64 sys
11:46 ~/Co/Ce/torchdft time pipenv install numpy --skip-lock
Installing numpy…
Collecting numpy
  Using cached https://files.pythonhosted.org/packages/f6/cd/b2c50b5190b66c711c23ef23c41d450297eb5a54d2033f8dcb3b8b13ac85/numpy-1.14.5-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
Installing collected packages: numpy
Successfully installed numpy-1.14.5

Adding numpy to Pipfile's [packages]…
        4.97 real         2.88 user         1.81 sys
11:46 ~/Co/Ce/torchdft time pipenv lock --verbose
Locking [dev-packages] dependencies…
Using pip: -i https://pypi.org/simple

                          ROUND 1                           
Current constraints:

Finding the best candidates:

Finding secondary dependencies:
------------------------------------------------------------
Result of round 1: stable, done

Locking [packages] dependencies…
Using pip: -i https://pypi.org/simple

                          ROUND 1                           
Current constraints:
  numpy

Finding the best candidates:
  found candidate numpy==1.14.5 (constraint was <any>)

Finding secondary dependencies:
  numpy==1.14.5 not in cache, need to check index
  numpy==1.14.5             requires -
------------------------------------------------------------
Result of round 1: stable, done

Updated Pipfile.lock (4fccdf)!
      219.24 real        25.14 user         5.77 sys

이제 Numpy가 훨씬 더 빨라야 합니다(사실 저는 귀하의 예제를 테스트 케이스로 사용하고 있습니다!). 가장 최근의 테스트에서 VM의 콜드 캐시에서 ~30초로 설정했습니다.

최신 릴리스에서 개선된 사항을 확인할 수 있습니까?

저에게도 상당히 개선되었습니다. 나는 지금 매우 빠른 연결에 앉아 있고 14초만큼 낮아졌지만 다운로드가 30MB/s로 진행되었을 때였습니다. numpy 소스 코드의 단일 사본 외에 다운로드되는 것은 무엇입니까?

중복 휠을 다운로드하고 있다고 생각합니다(확실하지 않음). 우리는 이미 상황을 평가하고 있습니다.

fe 변경 사항을 제거하고 이제 이를 다른 컴퓨터에 배포하여 Pipfile.lock을 크게 변경했습니다. 이에 대한 특정 수정 사항이 있습니까?

잠금 파일을 수동으로 편집하지 않는 것이 좋습니다. 추가 정보가 없으면 도움을 드릴 수 없습니다. 별도의 이슈를 열어주세요.

pipenv 잠금의 성능을 벤치마킹하려면 종속성에 pytmx를 추가해야 합니다...
pipenv 잠금은 우리에게 1시간 이상 걸렸고(인터넷 속도가 꽤 느림) pytmx를 제거한 후 약 5분으로 줄어들었고 마침내 pipenv가 더 유용해졌습니다.
나는 pytmx가 큰 모놀리식 lib이고 opengl/pygame 및 기타 관련 항목에 의존하기 때문에 큰 패키지라는 것을 알고 있지만 패키지가 얼마나 크더라도 pipenv 잠금에 1시간이 걸리지 않아야 합니다.

나에게 1시간도 걸리지 않아

$ cat Pipfile
[packages]
pytmx = "*"

$ time pipenv lock --clear
Locking [dev-packages] dependencies...
Locking [packages] dependencies...
Updated Pipfile.lock (eb50ab)!

real    0m2.827s
user    0m2.287s
sys 0m0.390s

또한 PyTMX는 PyPI에서 20kb 미만이고 6개(초소형)에 대한 종속성이 하나만 있으므로 네트워킹은 문제가 되지 않습니다. 귀하의 환경에서 다른 일이 일어나고 있을 가능성이 있습니다.

당신이 옳습니다. 파이 게임 등에 명시 적으로 의존하지 않는다고 생각했던 것보다 작습니다. 왜 그렇게 오래 걸렸는지 확실하지 않습니다!
더 많은 정보를 찾으려고 노력하겠지만 CPU와 SSD가 최고이므로 여전히 문제가 느린 인터넷과 관련이 있다고 생각합니다.

@techalchemy 파일을 수동으로 편집하지 않았습니다. pipenv uninstall package_name 사용하여 많은 종속성을 제거한 후 서버에서 실행했습니다. 아주 오랫동안 잠금 상태를 유지했습니다.

나는 어둠 속에서 무작위 샷으로 이 토론에 에너지를 소비하는 데 관심이 없습니다. 재현 가능한 테스트 케이스를 제공하십시오.

여기 재현 가능한 테스트 케이스가 있기를 바랍니다.
https://github.com/Mathspy/tic-tac-toe-NN/tree/ab6731d216c66f5e09a4dabbe383df6dc745ba18

하려고
pipenv install
이 잠금이 없는 저장소에서 표시되는 동안 지금까지 700MB 이상을 다운로드했습니다.
Locking [packages] dependencies...

잠시 후 중단하고 수정될 때까지 --skip-lock 다시 실행합니다.

lock 이 정말 느리고 files.pythonhosted.org 에서 scipy flask 등에 의존하는 소규모 프로젝트의 경우 800MB가 넘는 엄청난 양의 데이터를 다운로드한 것으로 나타났습니다.

그래서 files.pythonhosted.org 대한 요청을 스니핑했는데 pip 또는 pipenv가 완전히 불필요한 다운로드를 수행하고 있어 lock 고통스럽게 느려졌습니다.

예를 들어, 동일한 버전 numpy 이 전체를 여러 번 다운로드했습니다. 그리고 Mac을 사용하고 있었지만 Windows/Linux용 휠을 다운로드했습니다.

내 설정:

$ pipenv --version
pipenv, version 2018.05.18

$ pip -V
pip 18.0 from /usr/local/lib/python2.7/site-packages/pip (python 2.7)

여기에 디버깅에 도움이 되는 추가 Pipfiles가 있습니까?

대부분 @AlJohri , 실행 중인 프로세스/잠금/io에 대한 정보가 도움이 될 것입니다.

이미 약 5 분 동안 여기에 붙어 있습니다. 처음에는 일종의 pip 설치 문제일 수 있다고 생각하고 Homebrew를 통해 모든 것을 새로 다시 설치했지만 여전히 동일한 문제입니다. 어떤 아이디어가 있습니까?

약 6~7분 후 드디어 완성. Python과 Pipenv를 처음 접했으므로 디버깅에 필요한 파일을 찾는 데 약간의 도움이 될 것입니다! :)

이것은 새로운 python 라이브러리를 설치하거나 기존 라이브러리를 업그레이드하는 것을 두려워할 정도로 매우 나쁩니다.

제작자의 대화 중 하나를 본 후 pipenv 를 사용하기로 결정했습니다. 하지만 너무 느립니다.

통찰력 있는 피드백에 감사드립니다.

@techalchemy 이 문제를 해결하고 해결하기 위해 제가 할 수 있는 일이 있다면. 기여하게 되어 매우 기쁩니다.

lock 이 정말 느리고 files.pythonhosted.org 에서 scipy flask 등에 의존하는 소규모 프로젝트의 경우 800MB가 넘는 엄청난 양의 데이터를 다운로드한 것으로 나타났습니다.

결정적인 증거는 아니지만 scipy 가 매우 긴 pipenv 잠금 시간과 상관관계가 있다는 의심이 있습니다.

때때로 정말 고통스럽습니다. 저는 PyPDF2와 textract를 설치하고 있습니다. pipenv를 잠그는 데 ~10분이 걸렸습니다.

pipenv의 느림은 우리를 위한 개발 프로세스를 정말로 방해합니다. 이제 이 문제가 해결될 때까지 모든 사람에게 pip + virtualenv를 사용하도록 조언합니다.

이것에 대한 소식이 있습니까? 도울 방법이 없나요?
https://github.com/pypa/pipenv/issues/1914의 속임수

/ 편집: btw, pipenv install 가 잠금 파일의 버전을 업데이트하는 이유는 무엇입니까? o.Ò 잠금 시간이 초과된 후 방금 실행했는데 이제 새 잠금 파일을 보니 pandas가 0.23.4에서 0.24.0으로, numpy가 0.16.0에서 0.16.1로 업데이트되었습니다. 내가 pipenv update 하지 않는 한 그런 일이 일어날 것이라고 기대하지

빨리 설치하고 느리게 잠기므로 Installation Succeeded 메시지를 받는 즉시 계속 작업하는 것이 좋습니다... 다른 것을 설치하지 않으려면...

... 또는 잠금 파일을 일부 저장소에 푸시해야 합니다.

lock 가 이미 별도의 명령인 것을 볼 때 install 가 잠금을 수행해야 합니까? 한편 install 옵션 설명은 잠금도 발생하도록 지정해야 하며 --skip-lock 권장할 수도 있습니다.

또한 이 문제를 고정하는 것은 어떻습니까?

Pipenv는 정말 멋진 도구이고 추천하곤 했지만 8개의 모듈이 있는 프로젝트는 잠글 수 없습니다... 시간이 초과됩니다. 이 문제를 해결하는 데 관심이 없는 것 같고 매우 실망스럽습니다. 지금 pypy에서 다운로드하지 않고도 종속성을 얻을 수 있다는 것을 읽었습니다. 이것이 이 문제의 해결 방법입니까? 여기에서 해당 옵션에 대한 이야기를 볼 수 없습니다. 현재 이 도구는 내 목적에 사용할 수 없습니다.

pexpect.exceptions.TIMEOUT: <pexpect.popen_spawn.PopenSpawn object at 0x10e12e400> searcher: searcher_re: 0: re.compile('\n') <pexpect.popen_spawn.PopenSpawn object at 0x10e12e400> searcher: searcher_re: 0: re.compile('\n') pipenv lock -r 87.22s user 18.57s system 11% cpu 15:02.77 total

이것이 이 프로젝트의 주요 우선순위가 아닌 이유는 무엇입니까? Pipenv는 너무 느려서 거의 사용할 수 없습니다. 일부 드문 경우에만 사용하는 것이 아니라 항상 매우 느립니다.

내부에서 무슨 일이 일어나고 있는지에 대해 너무 많이 알지 못한 채 나는 이것이 종속성 그래프의 로컬 캐시로 훌륭하게 해결될 수 있다고 생각했습니다.

그것에 대해 생각 : 우리가 패키지를 캐시하는 경우 x-1.2.3 에 따라 y>=3.4 , 우리는 로컬 현재 종속성을 한 번에 패키지 하나를 다운로드를 확대하고, 확인에 끝낼 일을 많이 할 수 있습니다 . lock 단계는 다음과 같이 간단합니다.

• Pipfile을 캐시와 비교하고 필요한 모든 것이 있는지 확인하십시오.
• 그렇지 않은 경우 새로운 것을 다운로드하고 거기에서 종속성을 계산하십시오.
  
  
  
  • 변경 사항 캐시
  
  
• 설치.

모든 경우에 처음에는 느릴 수 있지만 후속 잠금은 고통스럽지 않을 것입니다. 그렇죠?

작은 프로젝트에 pip 대신 pipenv를 사용하기로 결정했습니다. 내가 한 첫 번째 일은 pipenv install -r requirements.txt 입니다. 약 10분 동안 종속성을 잠그고 있습니다. 그러므로 나는 핍으로 돌아갈 것이다.

여러분, 이 문제로 인해 많은 사용자가 비용을 지출하고 있습니다. 신속하게 처리할 것을 제안합니다.

제 경우에는 서버에 종속성을 설치하면 몇 시간 동안 서버가 중단됩니다. 1GB RAM이 있는 AWS EC2 인스턴스 t2.micro 하고 있습니다. 이 많은 RAM은 종속성이 거의 없는 단일 응용 프로그램에 충분하지만 설치 시 모든 메모리가 사용되며 서버를 다시 시작하여 작동하게 하는 방법은 한 가지뿐입니다.

이 문제는 수년 동안 보류 중이며 이에 대한 수정 사항이 없습니다. 해결 방법 없이 여러 문제가 종료되는 것을 봅니다.

그런 좋은 도구가 무시되고 있습니다. 이 문제는 절대 해결되지 않을 것 같아서 구독을 취소하겠습니다. conda와 같은 것을 고수하거나 virtualenv를 사용하여 수동으로 수행합니다.

https://github.com/sdispater/poetry에 한 번 도전해 보겠습니다:|

관리자가 이 스레드를 댓글로 닫을 수 있나요? 토론에 유용한 추가 콘텐츠가 추가되지 않은 것 같습니다.

문제 해결을 위한 작업을 추적하는 티켓을 구독하고 싶습니다.

감사 해요!

나는 이 도구를 사용하고 이 스레드에 대해 불평하는 사람들의 99%가 프로그래머라고 생각합니다. 징징대지 말고 입이 있는 곳에 시간을 두고 PR을 제출하세요.

안녕하세요 @idvorkin 입니다 .

나는 한 번 시도했다.
사소한 수정 사항을 병합하는 데 몇 주가 걸렸습니다.
토론의 양을 실제 수정 크기와 비교하기만 하면 됩니다.

이 프로젝트에 더 이상 수정 사항을 제출하고 싶지 않습니다.

따라서 귀하의 조언은 귀하가 생각하는 것만큼 실행 가능하지 않습니다.

많은 사용자를 대신하여 @Jamim (관리자도 의심됨), 기여해 주셔서 감사합니다. 나는 당신의 PR을 읽었고 그 좌절에 공감할 수 있었습니다. 그러나 나는 이것 에 대해

물론 우리는 우리가 유지 관리하는 라이브러리에 대해 관심을 갖고 있지만 긍정적인 상호 작용을 하는 가장 효과적인 방법은 구문이 아닐 수 있습니다.

나는 관리자를 만난 적이 없지만, 그들이 나와 같다면(그리고 아마도 당신도 마찬가지일 것입니다) 그들은 이 프로젝트에 쓸 에너지가 있기도 전에 약속으로 가득 찬 바쁜 삶을 사는 사람들입니다.

마찬가지로, 당신(또는 다른 누군가)이 성능 문제를 수정했다면, 당신이 그것을 개발, 테스트, 병합하는 데 도움을 줄 많은 사람들이 있을 것이라고 확신합니다. .

나는 이 프로젝트의 개발자들이 이것에 시간을 할애해줘서 고맙지만, 이 프로젝트가 README.md 의 사용자 평가 바로 위에 아직 프로덕션 준비가 되지 않았다는 것을 굵게 경고해야 한다고 제안합니다. 사람들이 이 느린 잠금에 대해 알아내고 사용할 수 없다는 것을 이해할 때까지 현재 pip/virtualenv 스택을 pipenv로 교체하는 데 귀중한 시간을 소비하도록 오도합니다.

그들이 이 느린 잠금에 대해 알아내고 그것을 사용할 수 없다는 것을 이해할 때까지.

실제로 매우 느리기 때문에 속도를 높이게 되어 매우 기쁩니다. 그러나 그러한 과장법은 필요하지 않습니다.

나는 매일 pipenv를 잘 사용하고 있습니다. 제공하는 워크플로 개선 사항은 가끔 발생하는 속도보다 훨씬 더 중요합니다. 잠금은 예를 들어 스크립트를 실행하는 것과는 달리 제가 항상 하는 것이 아닙니다.

얼마나 자주 당신이 그것을 사용할 수 없다고 느끼는 그러한 문제가 실제로 발생하도록 잠그고 있습니까? :open_mouth:

@bochecha 내 진술은 당신의 의견으로는 과장될 수 있지만 내 경험을 기반으로 한 사실입니다. 일부 동료로부터 pipenv에 대해 들었습니다. 오늘 나는 오래된 프로젝트를 업데이트하고 종속성을 업데이트하려고했습니다. pip/virtualenv에서 업데이트 할 수 있다고 생각했습니다. 업데이트 프로세스의 일부로 pipenv. 종속성을 업데이트하고 작동 방식을 확인하고 필요한 경우 코드 일부를 업데이트한 다음 다른 종속성을 업데이트해야 했습니다. pipenv install <something> 실행할 때마다 엄청나게 오랜 시간을 기다려야 했습니다. 처음에는 계산 중이라고 생각했습니다. 생산 준비 패키지 관리자라고 주장하는 것이 문제라는 것을 믿을 수 없었기 때문에 미래를 위해 캐시할 것입니다. ~10번째 패키지를 설치한 후 검색을 시작했고 이 스레드를 찾았습니다. Pipfile 및 Pipfile.lock 하고 pip/virtualenv 워크플로로 돌아갔습니다. 시를 써보고 싶었지만 한 시간도 더 걸을 수는 없었습니다.

이것은 예를 들어 JS 커뮤니티에서 발생하지만 Python 커뮤니티에서는 예상하지 않습니다. 우리 커뮤니티에는 이러한 종류의 문제가 없으며 우리는 이를 피하려고 노력해야 합니다. README.md 의 면책 조항은 피할 수 있습니다. 이 불편함을 내 의견에 제안했습니다. 오늘 제 시간을 절약할 수 있고 다른 신규 이민자의 시간을 절약할 수 있으며 이 프로젝트에 대해 나쁜 경험을 하지 않을 것이므로 잠재적인 미래 사용자로 남을 수 있습니다.

나는 sassanh에 어느 정도 동의합니다. 모든 사람이 이 문제에 동등하게 영향을 받는 것은 아니지만 우리 중 일부는 꽤 심하게 영향을 받았습니다. 저는 완전히 작동하지 않거나 프로덕션 준비가 되지 않은 오픈 소스 프로젝트를 만들었습니다. 그런 경우에 면책 조항을 넣어 사람들이 문제에 대한 준비가 되지 않은 경우 시간을 낭비하지 않습니다.

나는 이 프로젝트에 참여하는 사람들에게 화를 내지는 않지만 면책 조항이 없는 훌륭한 도구로 판매하여 이에 대해 공개적으로 이야기한 사람에게 화를 냈습니다. 결과적으로 나는 장기적으로 시간을 절약하기 위해 도구를 작동시키는 데 내 소중한 시간을 꽤 많이 낭비했지만 pipenv가 작동하지 않았기 때문에 결국 pip와 내 자신의 스크립트로 돌아가야 했습니다. 내 시간과 대역폭이 제한된 환경에서.

pipenv install을 실행할 때마다

기존 프로젝트에서 pipenv로 옮기려고 할 때 한 번만 잠그거나 설치하는 pipenv install -r requirements.txt 에 대해 알고 계셨습니까? 그렇지 않은 경우 문제가 문서 중 하나일 수 있습니까?

무엇보다 pipenv가 pip/virtualenv 워크플로의 좋은 대체품이 될 것이라고 확신합니다. 우리 모두는 그것이 필요하다는 것을 알고 있고 pipenv가 프로덕션 준비가 되는 날 많은 사람들/프로젝트에 큰 도움이 될 것이라고 생각합니다.

@bochecha 내가 설명한 대로 최신 버전의 패키지를 설치하고 몇 가지 작업을 수행한 다음 다음 패키지로 이동해야 합니다. 아마도 pip로 이 프로세스를 수행한 다음 pipenv로 마이그레이션하면 문제를 전혀 눈치채지 못할 것입니다. 하지만 먼저 pipenv로 마이그레이션한 다음 패키지 업데이트를 하나씩 수행했는데 정말 짜증이 났습니다. 귀하의 사용 사례에서 작동하게 되어 기쁩니다. 그러나 저와 같은 많은 사람들에게는 작동하지 않을 것이라고 확신합니다(위의 설명 참조). README.md 에 언급되어야 합니다. 최소한 "각 잠금에 시간이 오래 걸릴 수 있으므로 사용 사례에 많은 패키지를 빠르게 설치/제거하는 것이 포함되는 경우 이 문제가 해결될 때까지 pipenv를 사용하지 않는 것이 좋습니다. 해결됨"(다시 굵게, 후기 상단) 누군가가 영향을 받기 전에 문제를 발표하면 모두가 감사할 것이고, 문제가 다른 사람들에게 영향을 미치고 경고하지 않으면 모두가 화를 낼 것입니다.

동의. 나는 시를 조사하기 시작했고 pipenv를 다시 사용하는 대신 프로젝트별로 내 OS에 다른 사용자를 추가했지만. 기본 설정으로 캐주얼한 사용 사례에서 제대로 작동하지 않으면 imho 가 손상되었습니다.
매우 유용한 도구입니다! 나에게 그것을 매우 쓸모 없게 만드는 것은 단지 이것 하나뿐입니다. 그리고 슬프게도 기여할 시간이 거의 없습니다 :|

물론, 개발 세션 중 여러 설치를 수행해야 할 때 잠금을 기다리는 것은 성가신 일이지만 이것은 관리할 수 있습니다.

중요한 것은 로컬 변경 사항을 repo에 푸시하기 전에 잠금 파일이 생성된다는 것입니다. 나는 개발 세션 중에 —skip-lock 플래그를 신중하게 사용하고 커밋하기 전에 마지막에 pipenv lock 한 번 사용합니다.

프로젝트에 감사드립니다. 하지만,
잠그는 것은 verrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrywwwwwwwwwwwwwwwwwwwwwwwwwwww.

PIP_NO_CACHE_DIR=off
이 환경은 pip 패키지 캐시가 이미 설치된 경우 잠금을 더 빠르게 만듭니다.

안녕하세요 @yssource 와 여러분,

프로젝트에 감사드립니다. 하지만,
잠그는 것은 verrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrywwwwwwwwwwwwwwwwwwwwwwwwwwww.

이 프로젝트는 죽은 것 같으므로 속도 문제를 제거하려면 훨씬 더 빠른 Poetry 로 마이그레이션하는 것을 고려하십시오.

@Jamim , Poetry를 추천해주셔서 감사합니다. 개인적으로 어떤 이유로 나는 그것을 접하지 못했습니다. 읽어보기를 읽은 후에 시도해 볼 가치가 있는 것 같습니다. Pipenv에 대한 몇 가지 이점도 나열합니다(https://github.com/sdispater/poetry/#what-about-pipenv).

그렇긴 하지만, 프로젝트가 죽었다는 것은 너무 과장된 표현이며, 내가 pipenv 작성자의 입장이라면 무례하다는 것을 알게 될 것입니다. 작성자는 어제 문제 섹션에서 답변했습니다. 이 잠금 문제가 간과되고 있는 것은 아마도 해결하기 어렵기 때문일 것입니다.

기록을 위해 Poetry는 성능 문제도 겪고 있습니다.
https://github.com/sdispater/poetry/issues/338

내 모든 프로젝트에서 동일한 문제가 있습니다.
원인은 pylint인 것 같습니다.
Pipenv(pip)는 성공적으로 설치할 수 있지만 잠금은 영원히 걸립니다!
pipenv, version 2018.11.26

djbrown@DESKTOP-65P6D75:~$ mkdir test
djbrown@DESKTOP-65P6D75:~$ cd test
djbrown@DESKTOP-65P6D75:~/test$ pipenv install --dev pylint --verbose
Creating a virtualenv for this project…
Pipfile: /home/djbrown/test/Pipfile
Using /usr/bin/python3 (3.6.9) to create virtualenv…
⠸ Creating virtual environment...Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/python3
Also creating executable in /home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/python
Installing setuptools, pip, wheel...done.

✔ Successfully created virtual environment!
Virtualenv location: /home/djbrown/.local/share/virtualenvs/test-PW-auWy_
Creating a Pipfile for this project…
Installing pylint…
⠋ Installing...Installing 'pylint'
$ ['/home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/pip', 'install', '--verbose', '--upgrade', 'pylint', '-i', 'https://pypi.org/simple']
Adding pylint to Pipfile's [dev-packages]…
✔ Installation Succeeded
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
⠇ Locking...

pipenv 에 대해 많이 듣고 오늘 해봤는데,
잠금도 나에게 매우 느립니다. 이미 2분 정도 지났는데 여전히 잠김 상태입니다.
다운로드는 꽤 빠르지만 문제는 잠금입니다.
이 문제가 해결되었습니까?
apt, python 3.7.5의 Pop os 19.10, pipenv, 버전 11.9.0을 사용하고 있습니다.

동일한 주제 https://github.com/pypa/pipenv/issues/1914#issuecomment -457965038에 대한 #1914의 이 훌륭한 의견에 주목하고 싶습니다. 이는 각 종속성을 더 이상 다운로드하고 실행할 필요가 없음을 시사합니다.

어떤 개발자가 이 접근 방식의 타당성에 대해 논평할 수 있는지 궁금합니다.

환경을 제거하고 잠금 파일을 업데이트하기 위해 처음부터 다시 만드는 것이 실제로 더 빠르다는 것을 알았습니다.
pipenv lock 및 pipenv install some-package 실행 모두에 해당됩니다.

나는 pipenv 정말 좋아하지만 대역폭과 시간만큼은 아닙니다. 그래서 나는 다음을 사용하여 문제를 해결합니다.

$ pipenv --rm
$ virtualenv .
$ source bin/activate
$ # Create a requirement file (Cause pipenv lock -r > requirements.txt... you know!)
$ pip install -r requirement.txt

개발자 여러분의 건승을 빕니다...

@ravexina 제안 감사합니다, 확실히 시도하겠습니다