Pipenv: 목표: 모든 설치 명령 후 잠금 파일 일관성 보장

여기서 잠재적인 구현 문제를 언급합니다. pip-tools 현재 제약 조건 파일을 지원하는지 잘 모르겠습니다. 이 경우 이 접근 방식을 최대한 활용하려면 먼저 해당 지원을 추가해야 합니다.

그러나 pip가 실제 설치를 처리하는 데 사용되기 때문에 설치 시간 충돌 감지 는 상관없이 가능해야 합니다.

설치 시간 자체까지 기다릴 필요가 없습니다. 잠금 파일에 대한 전체 전이 종속성을 해결할 때 이를 수행할 수 있습니다.

https://github.com/pypa/pipenv/issues/966#issuecomment -339707418에서 관련 없는 종속성을 업데이트하지 말라는 @vphilippon 제안에 따라 대부분 LocalRequirementsRepository 이 작업을 수행할 수 있습니다. https://github.com/taion/pipf/blob/1feee35a2e4480bc7e5b53bfab17587d37bdf9dd/pipf/pipfile.py#L175 -L185처럼 보입니다.

https://github.com/pypa/pipfile/issues/100 도 Pipfile.lock 가 서로 다른 그룹에 대해 호환되지 않는 여러 종속성 집합을 나타낼 수 있다는 것은 여전히 ​​근본적인 문제입니다.

@taion 우리는 개발 종속성을 보지 않고 배포 종속성을 다시 잠그는 도구를 지원하기를 원하기 때문에 Pipfile.lock 를 평면 표현으로 전환하지 않을 것입니다. 예, 이는 [dev-packages] 섹션이 최신이 아닐 수 있음을 의미하지만 이것이 이 문제의 목적입니다. [dev-packages] 섹션이 업데이트될 때 해당 섹션이 배포 패키지 섹션.

하지만 설치 시간이 아닌 잠금 시간에 충돌을 감지할 수 있다면 훌륭할 것입니다.

실제로 사용자 관점에서는 https://github.com/pypa/pipenv/issues/966 및 기타 관련(닫힌) 문제의 특별한 경우일 뿐입니다.

최악의 경우처럼 잠금 파일에서 해결된 전이 종속성을 캐시하면 됩니다. Yarn과 npm은 이미 그렇게 합니다. 개발자 dep에 대해 PyPI를 누르지 않고 모든 prod dep를 업데이트할 수 있습니다.

내가 뭔가를 놓치고 있지 않는 한 동기화되지 않은 상태로 흘러가도록 내버려 두는 적극적인 이점이 없습니다. 이러한 패키지 관리 패턴에 많은 시간을 보낸 사람으로서 기존 도구가 작동하는 방식에서 이러한 편차의 대부분은 고통을 야기하는 것 같습니다.

또한 npm은 실제로 프로덕션 종속성 업데이트만 지원하고 개발 종속성은 지원하지 않으며 실제로 플랫 잠금 파일(캐시된 해상도 포함)을 사용한다고 덧붙입니다.

흥미롭게도 Yarn은 대량 "업데이트 종속성" 하위 명령을 사용하지 않으며(대화형 버전은 prod 및 dev deps를 분할하지만) 이에 대해 불평하는 사람이 없는 것 같지만 아마도 npm - 기본적으로 종속성에 대해 캐럿 범위를 사용하는 것과 유사하며 일반적으로 SemVer를 따르는 데 충분히 능숙하여 사용자에게 dev dep 충돌로 인한 문제를 거의 일으키지 않습니다. Python 생태계는 그다지 많지 않습니다.

@taion 명시적 pipenv lock 이미 [packages] 및 [dev-packages] 모두 완전히 해결하므로 이 경우 구성 드리프트에 대해 걱정할 필요가 없습니다. 종속성 충돌을 감지하는 것이 가장 바람직합니다).

pipenv install package 및 pipenv install --dev package 불일치를 감지(및 해결)할 수 있는 대칭 솔루션이 있다면 그것이 좋은 방법이 될 것이라는 데 동의합니다. 그러나 비대칭 솔루션이 구현하기 더 쉽다면(따라서 이 제안의 틀이 잡힘) 비대칭 솔루션도 괜찮을 것입니다.

대칭 접근 방식의 경우 @vphilippon 이 https://github.com/pypa/pipenv/issues/966#issuecomment -339791934에 설명된 접근 방식을 추구하는 것이 프레임 및 구현의 한 가지 방법이지만 다음과 같이 구성합니다. :

• 기본 포괄적인 업데이트가 아닌 최소한의 잠금 파일 업데이트를 요청하는 pipenv lock --keep-outdated 옵션 추가
• pipenv install package 를 "Pipfile 편집 -> pipenv lock --keep-outdated -> pipenv install "로 정의하도록 변경합니다.

(참고 : 보안 관리상의 이유로, 난 정말의 기본 동작을 유지하려면 pipenv lock 업그레이드 등 모든 것을 - 그러나, 나는 같은 기능을 생각 하는가 --keep-outdated 다른 메커니즘이 제자리에있을 때 장소를 가지고 종속성에서 보고된 보안 문제에 대한 적시 응답을 보장하기 위해)

pipenv install 대해 설명하는 동작은 대부분 #966이 얻는 것이지만 정확히 동일하지는 않습니다. X = "*" 가 있다고 상상해보십시오. 이렇게 pipenv install X 아마 여전히 업그레이드해야합니다 X 에 변화가 없다하더라도, 잠금 파일에 Pipfile . Pipenv는 _실제로_ 업데이트되는 내용을 추적해야 합니다.

즉, "잠금"에서 "설치"를 완전히 분리할 수 없습니다. 예를 들어 https://github.com/taion/pipf/blob/1feee35a2e4480bc7e5b53bfab17587d37bdf9dd/pipf/pipfile.py#L150 -L155를 참조하십시오. 잠금 파일을 재생성할 때 삭제하기 위해 설치되는 패키지에 대한 이전 제약 조건을 명시적으로 전달합니다. .

어쨌든 불만은 명시적인 pipenv lock 와 같은 것이 모든 종속성을 사용 가능한 최신으로 업데이트한다는 것이 아닙니다. pipenv install Y 가 관련 없는 X 의 버전을 건드리는 것입니다. 다시 말해서, 사람들은 실제로 pipenv lock --keep-outdated 를 명시적으로 실행할 필요가 없습니다.

여기에서 Yarn의 처리는 CLI 측면에서 꽤 좋은 예입니다. Yarn에는 아무 것도 변경하지 않고 잠금 파일을 생성하는 yarn lockfile 가 있으며 명시적으로 "[not] required"로 표시되어 있으며 모든 것을 업그레이드하는 yarn upgrade 가 있습니다. 어떤 이유로 종속성을 수동으로 편집하는 경우 다음 단계는 yarn install 를 실행하는 것입니다. 이는 잠금 파일을 (최소하게) 업데이트하고 필요한 패키지를 설치합니다.

업데이트된 종속성을 설치하는 것 외에는 잠금 파일을 명시적으로 생성할 필요가 없었으며 왜 그렇게 하고 싶은지 모르겠습니다. 설치된 종속성을 수정하기 위해 취하는 거의 모든 작업이 어쨌든 잠금 파일을 업데이트하기 때문에 잠금 패키지 관리자의 일반적인 작업이 아닙니다. 대신 사용자 대면 상호 작용 세트는 다음과 같습니다.

1. 모든 종속성 설치
2. 하나 이상의 특정 종속성 추가 또는 업그레이드
3. 모든 종속성 업그레이드

(1)과 (2)는 항상 내 잠금 파일에 최소한의 변경 사항을 적용해야 하며(또는 필요한 경우 생성해야 함), (3)은 본질적으로 기존 잠금 파일을 무시해야 합니다. 그러나 잠금 파일을 생성하는 것만으로도 (1)이면 충분합니다(어쨌든 모든 것이 설치된 개발 환경에서 실행될 것이기 때문입니다).

PS Yarn은 yarn install (모든 종속성 설치)에서 yarn add (종속성 추가)를 분할합니다. 처음에는 다소 혼란스럽고 짜증이 났지만 사용할수록 그 구분이 마음에 듭니다. 특정 종속성을 추가하고 _그리고_ 모든 프로젝트 종속성을 설치하는 단일 install 명령을 갖는 것은 생각해보면 이상합니다. 이 두 가지 행동은 같은 것이 아닙니다.

https://lwn.net/Articles/711906/ 의 처음 몇 단락은 여기에서 내 사고방식을 잘 설명하고 있습니다. "움직이는 대상"은 모든 프로젝트의 기본 보안 모델이어야 하며 이를 옵트아웃해야 합니다. "단단한 벙커" 접근 방식은 절충점을 고려한 후에만 신중한 설계 결정을 내려야 합니다.

따라서 옵션 이름도 선택합니다. --keep-outdated 는 pip list --outdated 에서 영감을 받은 것이 아니라 명령줄에서 의심스럽게 보이도록 의도적으로 선택되었습니다. 보안 관점).

pipenv install X 의 특정 경우 에는 암시적으로 업그레이드를 수행하지 않아야 합니다. pip install X 는 암시적으로 업그레이드를 수행하지 않기 때문입니다.

pipenv 는 현재 후자의 점과 관련하여 다음을 수행하므로 일관성이 없습니다.

• pip install package 호출(암시적 업그레이드 없음)
• pipenv lock 호출(암시적 업그레이드)

따라서 항상 잠금 파일을 사용하여 설치를 유도하고( --skip-lock 가 사용되지 않는 한) 일관성을 보장하고 pip의 only-if-needed 업그레이드 전략과 일치하도록 pipenv lock --keep-outdated 를 제공한다는 아이디어입니다.

나는 우리가 의존성을 업그레이드하는 것이 바람직하다는 실질적인 요점에 동의한다고 생각합니다.

그리고 물론 pipenv install -U <package> 단일 패키지를 업데이트하는 것은 Pip과 병행하는 것이 좋습니다.

하지만 일반적인 워크플로에서 사용자는 --keep-outdated 또는 기타 없이 pipenv lock 를 실행할 이유가 없습니다. 사용자가 다양한 시나리오에서 실행할 수 있는 명령 세트는 다음과 같습니다.

• 새로운 패키지 부트스트랩: pipenv init
• 프로젝트의 새 클론 설정: pipenv install
• 새 종속성 추가: pipenv install <package> (그리고 Yarn이 이것을 add 라고 부르는 것을 다시 주목하세요. 이는 좋은 생각입니다)
• Pipfile 수동으로 편집한 후 설치된 종속성을 다시 동기화하십시오: pipenv install
• 모든 종속성을 최신 호환 버전으로 업그레이드: pipenv update

위의 모든 작업은 Pipfile.lock 를 동기화 상태로 유지합니다.

또는 달리 말하면 npm shrinkwrap (npm 5 사용)을 실행할 필요가 없었고 yarn lockfile 를 실행할 필요가 없었습니다.

(그리고 업데이트된 종속성이 있는 잠금 파일을 생성하는 것이 그다지 유용하지 않은 이유는 개발 워크플로의 바로 다음 단계가 업데이트된 종속성을 다시 설치하고 테스트 스위트를 실행하는 것이기 때문입니다.)

FWIW, 내가 종속 업데이트의 PR 자동으로 (생성하는 도구를 실행 Dependabot을 Pipfiles 위해 포함하여), 그리고 나는 사랑 pipenv lock --keep-outdated 옵션을 선택합니다. 현재 Pipfiles를 편집하여 PR을 생성할 때 업데이트하는 종속성을 제외한 모든 종속성을 잠급니다.

내 경험상 단일 종속성을 업데이트하는 PR은 한 번에 많은 종속성을 업데이트하는 PR보다 병합될 가능성이

맞습니다. 그리고 PR 생성은 pipenv lock --keep-outdated 가 유용할 것이라고 생각하는 곳입니다. "pipenv install && run tests" 단계는 PR이 생성된 시스템이 아니라 CI 서버에서 원격으로 발생할 것이라고 가정합니다. 마찬가지로 pipenv lock 는 변경 사항을 로컬에 적용하는 것에 대해 지나치게 걱정하지 않고 CI에서 테스트할 일괄 업데이트 PR을 생성하려는 경우입니다.

그런 맥락에서 pipenv install <requirement> 가 "update Pipfile + pipenv lock --keep-outdated + pipenv install "와 동등해진다면 pipenv update 가 동등해지는 것이 합리적입니다. pipenv lock && pipenv install .

하지만 yarn 구별하게 yarn install 및 yarn add , 우리가 이제까지 그러한 구분을 추가한다면 pipenv , 나는 더 빌려 경사 할 것 pip-tools 용어에서 pipenv sync 명령을 추가하여 "현재 환경을 잠금 파일과 일치시키십시오"라고 말합니다. 그러나 그렇게 하는 것은 이 제안의 범위를 벗어납니다. 특히 배포 종속성과 개발 종속성 간에 불일치가 발생할 기회를 제거하는 데 중점을 두어야 합니다.

@greysteil

Greenkeeper/&c에 해당합니다. npm의 사용 사례는 다음과 같습니다. 맞죠?

$ npm install --package-lock-only <package><strong i="8">@latest</strong>

사실 npm5도 만들 _just_ 수있는 방법 노출 않습니다 package-lock.json 외부 npm install ?

@ncoghlan

Greenkeeper와 같은 서비스는 매우 훌륭하고 사용할 가치가 있지만 핵심 사용 사례를 고려하는 것은 이상할 것입니다. 더 깨끗한 표현을 인정합니다).

앗, 너무 빨리 엔터를 쳤습니다. Greenkeeper 스타일의 워크플로를 제외하고 로컬에서 동기화하지 않고 종속성을 _그냥_ 범하는 것은 거의 사라져 버릴 정도로 드문 일입니다. 어떻게든 deps의 로컬 복사본이 설치되어 있지 않은 경우에만 의미가 있습니다. 그리고 다시 PR 전용 서비스는 예외입니다.

여기의 설명은 " 인간을 위한 Python 개발 워크플로"이므로 실제 개발 워크플로가 어떻게 생겼는지 염두에 둘 가치가 있습니다. 그리고 우리는 "록파일 생성" 작업을 명시적으로 실행하는 것이 거의 필요하지 않다는 꽤 좋은 존재 증거를 가지고 있으므로 이에 대해 너무 많이 생각하지 않는 것이 좋습니다.

여기서 특정 문제인 BTW는 Pipenv가 기본적으로 * 범위를 사용한다는 것입니다. pipenv install flask 하면 flask = "*" 에 Pipfile 됩니다. 즉, 설치된 Flask 버전을 깔끔한 방식으로 업그레이드하려는 경우 잠금 파일 전용 변경이 필요합니다.

업그레이드 작업은 원칙적으로 * 요구 사항을 >= 범위 또는 Pipfile 에 있는 것으로 전환할 수 있지만 이는 "업그레이드"와 "초기 설치" 사이에 이상한 비대칭을 만듭니다. 여기에서 가장 좋은 해결 방법은 어쨌든 초기 설치에 >= 범위를 사용하는 것입니다. 적어도 거기에서 * 범위를 사용해야 하는 타당한 이유가 있는지 확신할 수 없습니다.

@taion - 네, 동의합니다. 여러분이 우리/다른 종속성 업데이트 도구를 너무 많이 염두에 두기를 기대하지는 않지만 그렇게 하면 매우 감사합니다! 내가 이전 직장에서 종속성을 업데이트했다면 수동으로 pipenv lock --keep-outdated 사용했을 것이라는 것을 알고 있기 때문에 언급한 것 뿐입니다(우리는 종속성 업데이트 정책당 하나의 PR을 가짐).

참고로 npm 는 최신 릴리스( changelog )에서 package-lock-only 옵션을 추가했습니다.

@greysteil * 범위가 Pipfile 이면 어떻게 하시겠습니까? 위의 flask = "*" 예와 같습니다. 이것이 Pipenv가 기본적으로 종속성을 추가하는 방식이라는 점을 감안할 때 잠금 파일을 다시 빌드할 때 고정을 해제해야 하는 요구 사항을 알아야 합니다. 아니요?

_나는 이 스레드의 다른 사람들이 수행하는 세부 사항 근처에서 Pipenv의 작업을 이해하지 못하며 주제에서 벗어나고 싶지 않습니다. 아래가 유용하다면 좋습니다. 그렇지 않다면 죄송합니다!_

우리는 불쾌한 hax를 사용합니다:

• 업데이트할 버전을 찾기 위해 현재 최신 버전을 얻습니다( pip-tool 의 리졸버를 사용해야 하지만 아직 사용하지 않습니다. 해결할 수 없는 경우 다음 단계에서 오류가 발생하므로 나쁘지 않습니다. )
• 해당 (최상위) 종속성만 업데이트하는 Pipfile.lock 를 생성하려면
  
  
  
  1. 최신 버전을 지원하기 위해 업데이트하는 종속성에 대한 Pipfile 항목 업데이트
  
  
  2. 기존 잠금 파일 구문 분석
  
  
  3. 다른 모든 종속성에 대한 요구 사항을 잠금 파일에서 해결된 항목으로 설정하도록 Pipfile을 업데이트합니다.
  
  
  4. pipenv lock 를 실행하여 새 잠금 파일 생성
  
  
  5. 새로 생성된 잠금 파일의 해시를 3단계를 수행하지 않은 상태로 업데이트합니다(정말 제거하고 싶은 끔찍한 해킹).
  
  

최종 결과는 사용자가 Pipfile 변경되지 않은 PR을 얻지 * ) Pipfile.lock 가 해당 종속성의 최신 버전을 사용하도록 업데이트된다는 것입니다.

내가 이해하는 한 pipenv lock --keep-outdated 를 사용하면 대신 다음 흐름을 사용할 수 있습니다.

1. 최신 버전 과 동일 하도록 업데이트하는 종속성에 대한 요구 사항 업데이트
2. pipenv lock --keep-outdated 를 실행하여 새 잠금 파일 생성
3. 최신 버전을 지원 하도록 Pipfile만 업데이트했다면 새로 생성된 잠금 파일의 해시를 업데이트하십시오.

그래서, 그것은 무리가 더 좋을 것입니다. pipenv lock --keep-outdated <some_package_name> 를 실행할 수 있는 것이 이상적이지만 거지는 선택자가 될 수 없습니다! :옥토캣:

내 Pipfile에 다음이 있다고 가정합니다.

flask = "*"
numpy = "*"

flask 는 werkzeug 에 이행적으로 의존합니다. flask 및 numpy 에 사용할 수 있는 업그레이드가 있고 flask 버전을 업그레이드하지만 numpy 버전은 업그레이드하지 않는다고 가정합니다.

Pipenv를 사용하지 않았다면 다음을 실행했을 것입니다.

$ pip install -U flask
$ pip freeze > requirements.txt

pip-tools를 사용하는 경우 다음을 실행합니다.

$ pip-compile -P flask
$ pip-sync # Or: pip install -r requirements.txt

글쎄요, 그냥 pipenv lock --keep-outdated 가상으로 하는 것만으로는 아무 소용이 없습니다. 반면에 잠금 파일을 완전히 다시 빌드하면 NumPy도 업그레이드됩니다.

하지만 오해가있어하지 않는 한, 위에서 설명하는 전략 만의 버전으로 업데이트 할 것입니다 flask 잠금 파일에 있지만 버전 werkzeug . flask 의 새 버전이 werkzeug 의 새 버전도 _필요_한 경우 이는 잘못된 종속성 세트일 수 있습니다.

따라서 사람이 종속성을 업그레이드하는 데 매우 일반적인 사용 사례라고 생각하는 이 경우 단일 패키지와 해당 전이 종속성(필요한 경우)을 업그레이드할 수 있는 방법이 있어야 하지만 다른 방법은 없습니다.

여기서 문제는 특히 * 종속성입니다. npm이 이것을 처리하는 방법은 다음과 같이 시작하는 것입니다.

flask = ">=0.12.1"

그런 다음 업그레이드를 요청할 때 다음과 같이 변경합니다.

flask = ">=0.12.2"

이 경우 pipenv lock --keep-outdated 와 같은 것을 실행하는 위의 전략이 올바른 일을 할 것입니다. 당신이 사용하는 경우 그러나 * 범위를 다음 내가 좋아하는 몇 가지 특별한 도구없이 할 수있는 진정한 방법이 표시되지 않습니다 pipenv install -U flask 다음 떨어질 것을, flask 특별히 잠금 파일을 다시 빌드할 때 제안된 핀입니다.

죄송합니다. 위의 (iii) 단계에 대해 충분히 이해하지 못했습니다. 잠금 파일의 버전에 대한 모든 최상위 종속성을 잠그지만 하위 종속성은 잠금 해제된 상태로 둡니다.

@greysteil 내가 볼 수 있습니다. 그래서 잠재적으로 다른 직접 종속성의 전이 종속성을 업그레이드할 수 있습니까?

예 - 이론은 최상위 종속성이 하위 종속성을 적절하게 지정하는 경우(즉, 비관적으로) 하위 종속성을 업데이트하는 것이 위험하지 않아야 한다는 것입니다.

(나는 오히려 업데이트되는 종속성의 하위 종속성만 업데이트할 수 있는 Ruby's Bundler에 더 가깝지만 그렇게 하기 위한 강력한 pipenv는 해커의 가치가 없는 것처럼 보였습니다.)

@taion 기본적 으로 pipenv 은 LCA 강연에서 설명한 "움직이는 표적" 보안 모델에 거의 전적으로 초점을 맞추고 있습니다. 따라서 두 가지 의도된 사용 모델은 다음과 같습니다.

• 대화식 일괄 업데이트:

  • 사람은 주기적으로 일부 작업(명시적 일괄 업데이트, 새 종속성 추가, 명시적 종속성 업그레이드)을 수행합니다.
  • 이러한 작업의 일부로 잠금 파일과 현재 환경이 Pipfile 표시된 제약 조건을 충족하는 모든 항목의 최신 버전으로 업데이트됩니다.
  • 시간이 지남에 따라 이 작업 방식이 고통스럽지 않을 때까지 표현된 제약 조건이 업데이트되고 선택된 종속성이 전환됩니다. 그렇지 않으면 개발자가 아래의 두 번째 옵션으로 전환합니다.

• 자동 선택 업데이트:

  • 자동화된 프로세스는 종속성의 새 버전을 계속 감시하고 사용 가능해질 때마다 문제+PR을 제출합니다.
  • 인간은 주로 새로운 환경을 설정하고, 의존성을 명시적으로 추가하고, 기존 의존성에 대한 표현된 제약을 조정합니다.

이제 현재 두 사용 모델에 영향을 미치는 CLI 설계 및 구현 문제가 있습니다. 대화식 배치 업데이트의 경우 잠금 파일과 로컬 환경이 동기화되지 않는 방법이 있고 자동화된 선택적 업데이트의 경우 다음과 같은 문제가 있습니다. 선택적 업데이트를 수행하는 도구를 구현하고 관련 대화형 선택적 작업을 활성화하여 새 종속성을 추가하고 기존 종속성에 대한 제약 조건을 수정할 수 있습니다.

그러나 " Pipfile 에서 명시적으로 달리 명시하지 않는 한 모든 것의 최신 버전을 기본으로 실행"이라는 핵심 설계 철학은 변경되지 않을 것입니다. 잠금 파일 업데이트는 사람이 제출하는 것이 아니라 업데이트 관리 서비스에서 제출합니다.

자동화된 도구가 @ncoghlan에 대해 생각하고 있는 사용 사례라는 것을 읽게 되어 기쁩니다. 🎉

Dependabot/다른 사람들이 원하거나/필요로 하는 것에 대한 피드백을 원하시면 저에게 알려주십시오. 파이썬은 제 모국어가 아니므로 아직 pip/pipenv에 기여할 수는 없지만 제가 할 수 있는 모든 방법으로 돕고 싶습니다.

@ncoghlan 저는 여기에 전적으로 동의하며 귀하가 설명한 접근 방식이 의미가 있다고 생각합니다. LocalRequirementsRepository 사용하는 것은 코드 관점에서 구현하는 것이 그리 어렵지 않으며 이는 프로젝트에 대한 제 생각과도 일치하며 이 토론은 매우 생산적이었습니다.

@techalchemy 좋아요, 대칭 제안을 다루기 위해 초기 게시물을 수정하겠습니다(즉, 지금 하는 방식으로 설치를 먼저 실행하는 대신 pipenv lock --keep-outdated + pipenv install --ignore-pipfile 통해 새 패키지 설치를 처리함) .

이는 여전히 몇 가지 미해결 질문(예 --skip-lock 이 해당 모델에서 작동해야 함)을 남길 수 있지만 개별 기능 요청( --keep-outdated 을 pipenv lock 추가하는 것과 같은)을 분류하기 시작하기에 충분해야 합니다. 필요한 경우에만 업그레이드 전략을 요청하는 경우

좋습니다. 잠금 파일과 로컬 환경을 동기화하기가 정말 어려운 상태에 도달할 수 있도록 하는 몇 가지 제안된 하위 단계로 초기 게시물을 업데이트했습니다.

제안된 하위 단계 중에서 pipenv sync 하위 명령과 pipenv lock --keep-outdated 옵션은 이미 관심 있는 사람들이 구현을 살펴보기에 충분히 명확하지만 다른 모든 작업의 ​​의미 체계를 재정의하는 아이디어는 Pipfile 편집 및 pipenv lock 및 pipenv sync 의 동작 측면에서 패키지를 설치하거나 업데이트할 수 있는 것은 추가 논의가 필요할 수 있습니다.

좋아 보인다. 공개 질문에 대해 저는 pip install --selective-upgrade <package> 대해 제안된 동작에 전적으로 동의합니다(즉, 새 버전이 제공되지 않는 한 기존 버전 제약 조건을 준수하는 업그레이드 수행). 이것이 단일 패키지를 업데이트할 때 종종 원하는 동작입니다. < 2.0 제약 조건이 있는 곳에서 pip install --selective-upgrade django 실행하는 사람들을 상상할 수 있습니다.

위의 사본 중 일부를 명확히 할 가치가 있습니다. 제안된 pipenv install --selective-upgrade 는 사실상 표준 pip install -U 와 거의 동일해야 합니다.

그리고 다시, 실제로 사람들은 다른 패키지 관리자를 구축할 때 이것에 대해 많이 생각했습니다. 아마도 진공 상태에서 https://github.com/pypa/pipenv/issues/1255#issuecomment -355435921에서 설명하는 워크플로는 의미가 있지만, 예를 들어 여기에서 "인간을 위한 Python 개발 워크플로"를 구축하는 것이 목표입니다. 아니면 새로운 개발 워크플로를 실험하기 위한 것입니까?

Pipenv는 많은 것을 더 좋게 만드는 정말 멋진 프로젝트이지만 여기 목표에 꽤 근본적인 혼란이 있다고 생각합니다. 잠금 패키지 관리자는 요즘 거의 표준이며 Python에 축복이 있는 것은 좋지만 "새로운 이론적 패키지 관리 워크플로 탐색"과 "사람들이 기대하는 방식으로 작동하는 패키지 관리 워크플로 구축"을 혼동하지 않는다고 생각합니다. "는 긍정적이다.

다시 말하지만, 예를 들어 http://bundler.io/v1.16/man/bundle-install.1.html#CONSERVATIVE -UPDATING 및 기타 여러 가지에 유의하십시오.

여기서 내 마음이 바뀌는 것은 이러한 기존 도구 중 일부를 광범위하게 사용했으며 개발 워크플로가 부족하다는 것을 증명할 수 있다는 것입니다. 그러나 인간으로서 Pipenv가 이유에 관계없이 이러한 비정상적인 기본값을 적용하는 것을 보는 것은 즐거운 DX를 만들지 못한다는 것을 말씀드릴 수 있습니다.

리트머스 테스트를 보다 명확하게 하려면:

1. npm, Yarn 또는 Bundler와 같은 도구를 광범위하게 사용해 보셨습니까?
2. 그렇다면 npm i , yarn add 및 bundle update <gem> / bundle add 가 다른 모든 종속성을 건드리지 않는 문제가 발생했습니까?
3. npm up , yarn upgrade 또는 bundle update 를 실행하는 것이 번거롭습니까?

그렇지 않다면 기본적으로 여기에서 기본적으로 목표는 사용자가 기대하는 대로 작동하는 도구를 구축하는 것이 아니라 새로운 워크플로를 위한 전도인 것 같습니다.

그렇지 않으면 이것은 의도적으로 예기치 않은 기본값을 선택하는 연습처럼 보입니다. 이 기본값은 "인간을 위한"이라고 설명하는 패키지에서 기대하는 것이 아니라 네트워크에서 사용자를 좌절시킬 뿐입니다.

@taion 예, 모든 종속성에 대한 암시적 배치 업데이트를 위해 적극적으로 사람들을 밀어붙이는 것은 의도적입니다. 예, 저는 다양한 패키지 관리자에 대한 광범위한 경험이 있습니다. 내 경험에 따르면 기존 기본값의 결과는 사람들이 사용하는 구성 요소의 구식 버전을 정기적으로 실행하고, CVE를 확인 하지 않으며 , 다른 구성 요소가 강제로 업그레이드할 때만 업데이트하고, 그 접근 방식이 매우 높다는

따라서 pipenv 경우 다른 패키지 관리자 및 기존 서버 운영 체제를 따르기보다는 모바일 및 최신 데스크톱 운영 체제(즉, 회피하기 위해 의도적인 조치가 필요한 자동 업데이트를 기본값으로 설정)에서 의도적으로 신호를 취하고 있습니다. 그것이 어떻게 작동하는지 모른다는 것이 아니라 전통적인 기본 행동의 전형적인 결과가 나쁘다고 생각하고 그것을 피하려고 노력하기 때문입니다.

--keep-outdated (및 해당 PIPENV_KEEP_OUTDATED=1 환경 변수)를 추가하면 더 숙련된 개발자가 "내가 하는 일을 알고 있으며, 내 종속성을 책임감 있게 관리할 수 있도록 나를 신뢰할 수 있습니다"라고 명시적으로 말할 수 있습니다.

--selective-upgrade 미해결 질문을 제거하고 해당 세부 정보를 제안된 기능에 대한 설명에 포함시켰습니다.

그러나 pipenv uninstall 와 관련된 새로운 공개 질문을 추가했습니다. pipenv install 가 기본적으로 pipenv update 를 암시하는 것을 방어할 준비가 되어 있지만(@taion과의 위의 논의에 따라) pipenv uninstall 하는 것은 저에게 훨씬 덜 방어적으로 보입니다. 종속성을 제거하는 작업을 수행하는 것은 다른 구성 요소의 업그레이드로 인해 잠재적으로 새로운 전이 종속성을 추가하는 것이 매우 이상할 것입니다.

공개 질문에서 자동화된 종속성 업데이트 도구의 세계에서 pipenv install --skip-lock 대한 사용을 볼 수 없습니다. 사람이 사용하는 사례가 없다면(생각할 수 없음) 중복으로 간주하는 것이 안전하다고 생각합니다.

np 는 --no-package-lock (및 이에 상응하는 Yarn)를 사용합니다. 이 아이디어는 잠금 파일을 명시적으로 무시하고 최신 호환 범위로 잠금 해제된 모든 npm 종속성을 사용하여 테스트를 실행하는 것입니다.

특정 사용 사례는 tox의 존재(및 Python용 np와 같은 것을 구축하는 어려움)를 감안할 때 덜 관련성이 있을 수 있지만 라이브러리와 같은 경우에도 잠긴 종속성 세트를 모두 갖는 것이 합리적입니다. 뛰어드는 사람들이 깨진 빌드 환경을 처리할 필요가 없으며 사람들이 릴리스 전에 최신 호환 종속성에 대해 테스트할 수 있도록 합니다.

예, 테스트 사용 사례를 확실히 볼 수 있지만 나에게 덜 명확해진 부분은 해당 상황에서 잠금 파일을 수정하지 않은 상태로 두는 이점입니다(특히 pipenv update 는 현재 해당 옵션을 제공

• 순전히 CI에서 테스트하기 위한 것이라면 CI 서버는 git push 수행하지 않으므로 잠금 파일 수정은 다른 곳에서는 나타나지 않습니다.
• 소스 제어가 주어지면 로컬 잠금 파일 변경 사항을 유지하지 않으려면 되돌릴 수 있습니다.

잠금 메커니즘과 선언된 Pipfile 제약 조건을 완전히 우회하는 pip install --upgrade <whatever> 있습니다.

그 이후 지금, 옵션, 의미가 가장 가까운 해당 pipenv 로 현재 이벤트 pipenv --keep-outdated (당신이 뭔가를 추가 할 수있다 Pipfile 자동 업데이트 모든 것들없이).

지금은 미해결 질문으로 남겨두겠습니다. pip lock --keep-outdated 및 pip install --keep-outdated 가 존재하면 정답이 더 명확해질 것입니다.

제안된 변경 사항이 여전히 [packages] 와 [dev-packages] 사이의 불일치를 수정할 것으로 예상됩니까? 특히, 이 문제를 언급하는 #1220을 실행하고 있었지만 제안된 변경 사항이 그 불일치를 어떻게 수정할지 알 수 없습니다. 아니면 dev/non-dev 불일치가 #1220에 설명된 것과 다르며 해당 문제는 별도로 조사해야 합니까?

@matthijskooijman 상단 게시물에 명시적으로 명시되어 있지는 않지만 https://github.com/pypa/pipenv/issues/1255#issuecomment -354585775(현재 게시물에서 언급됨)에는 다음 중 하나가 있어야 한다고 명시되어 있습니다. packages 및 dev-packages 에서 "비일관성을 감지(및 해결)"하는 방법 또는 대안이 필요합니다. 이것은 나에게 불일치가 해결될 것임을 의미합니다.

의도는 해당 불일치가 pipenv lock 단계에서 해결되는 것입니다( 그러면 pipenv sync 는 자체 일관된 잠금 파일을 상속합니다).

(참고: 이것은 이전에 명확하지 않았으므로 해당 단계를 호출하는 별도의 글머리 기호를 추가했습니다.)

방금 CPython과 PyPy 간에 기본 Python 구현을 변경할 때 pipenv가 잠금 파일을 재생성하지 않는다는 것을 알아차렸습니다.

1. pipenv install --python pypy venv 생성 및 설치
2. 가상 환경을 삭제
3. pipenv install venv를 다시 만들고 설치하십시오.
4. 잠금 파일이 재생성되지 않고 host-environment-markers 섹션에는 여전히 "platform_python_implementation": "PyPy"

@joshfriend 실제로 의도적인 것이지만 현재 문제가 있는 이유에 대한 의견은 https://github.com/pypa/pipenv/issues/857#issuecomment -368223561을 참조

인수 없이 pipenv 설치에 대한 현재 동작을 유지하지만 새로운 환경을 설정할 때 pipenv sync 사용을 권장하도록 전환합니다(그런 식으로 pipenv install은 설치된 구성 요소를 변경하는 데 주로 사용됨)

이제 install 가 sync install 호출하므로 사용자가 install 를 사용하여 새 프로젝트를 부스트랩하도록 허용할 수 있습니다.

[패키지] 및 [개발 패키지]가 서로 일치하도록 항상 pipenv 잠금을 업데이트합니다(#1137에 대한 해결).

나는 방금 이것을 찔렀다 https://github.com/pypa/pipenv/commit/fdebdc3c423dce83c13d4e384acb703291109f1e

확실히 구현 세부 정보가 있지만(예: 개발 패키지에는 존재하지만 기본 패키지에는 없는 하위 뎁은 제거되지 않음) 확실한 개선 사항입니다.

구현 세부 정보를 수정했습니다. https://github.com/pypa/pipenv/commit/daa56e1290b259af8e2410b2f4d799ca71601a37

@kennethreitz 새로 설치하는 경우 pipenv install 잘 읽는 것에 관한 좋은 점: 재동기화의 경우에만 이상하게 읽혀 결국 버전을 일치시키기 위해 업그레이드 및 다운그레이드를 수행할 수 있습니다. pipenv sync 추천에 대한 글머리 기호를 완료로 표시하고 변경하지 않기로 결정한 부분을 확인했습니다.

#1137 변경 사항을 구현하면 #966을 함께 구현하는 --keep-outdated 및 --selective-upgrade 개선 사항만 남습니다.

# 1486에 대한 선택의 구현 방법, 주어진 --selective-upgrade 기능을 전달하는 필요성을 것입니다 --upgrade-strategy=only-if-needed 기본에 pip install 설정에 추가로 호출 keep_outdated 할 때 오래된 잠금 파일을 업데이트하는 중입니다.

지금 --keep-outdated 중 :)

$ pipenv lock --keep-outdated 이제 버전 번호가 고정되지 않는 한 이전 잠금 파일의 모든 버전 번호를 유지합니다.

또한 추가 Pipfile 구성 옵션이 추가되었습니다(현재 allow_prereleases ): keep_outdated :

[pipenv]

keep_outdated = true

--selective-upgrade 가 완료되었습니다.

후자! #857에서 아직 다루지 않은 추가 제한 사항이 10.1 릴리스 이후에 새로운 문제로 보고될 수 있으므로 이것을 닫습니다. :)

버그에 대해 작업 중이지만 곧 해결될 것입니다.

결정된