이것은 매우 인상적입니다. 컴파일해주셔서 감사합니다. 조금 더 자세히 리뷰하겠습니다.

/cc @uranusjr @jtratner @ncoghlan

maya 문제에 대한 일부 참조:

• kennethreitz/maya#138(RemovePipfile.lock을 저장소에서)
• kennethreitz/maya#139(tox.ini에서 pipenv 실행 건너뛰기 ...)
• kennethreitz/maya#145(setup.py에서 pendulum>=1.0 수정: 버전이 Pipfile에 있었지만 setup.py에서 누락됨)
• kennethreitz/maya#143( pipenv 문제가 전체 Travis 실행을 중단시킨 방법을 보여주는 PR)
• kennethreitz/maya#144(준공식 모범 사례에 따른 PR 리팩터 pipenv 사용)

나도 이것을 좋아한다. Pipenv의 문서나 Python Packaging User Guide 에 이것을 추가해야 할 수도 있습니다.

위 조언의 결과는 "결정론적/재현 가능한 CI 빌드를 포기"한 것으로 보이며, 이는 저에게 매우 큰 반패턴으로 보입니다.

여전히 결정론을 허용할 대안으로 무엇을 제안하고 있습니까?

@tsiq-oliverc 결정적 빌드는 현재 그 자리를 차지하고 있으며 애플리케이션을 빌드할 예정입니다.

Python 라이브러리의 결정론적 빌드를 수행하려는 다음 시도를 상상해 보십시오.

• 빌드는 Pipfile.lock 기반으로 해야 합니다.
• 각 실행 컨텍스트(각 파이썬 및 OS 변형의 조합)는 Pipfile 정의된 라이브러리 추상 종속성으로 인해 서로 다른 Pipfile.lock 가질 수 있습니다.
• 저장소는 저장소에 정의된 별도의 Pipfile.lock 인스턴스를 제공해야 합니다. CI 빌드 중에 Pipfile.lock 자동으로 빌드하면 결정성이 추가되지 않습니다.

이것은 많은 추가 노력입니다. 그리고 당신이 얻는 것은 다른 컨텍스트에 설치될 라이브러리이며(예: 1주일 후에 표준 설치가 업그레이드된 종속성을 선택합니다) 사실에서 아무 것도 얻지 못하는 Pipfile.lock 를 사용했습니다. 현재는 사용되지 않습니다.

충돌은 라이브러리가 내부에 엄격한 종속성을 정의해서는 안 된다는 사실입니다.

python 라이브러리에 대한 결정론적 빌드를 얻는 또 다른 대안이 있다고 생각한다면 설명하십시오.

@vlcinsky - 라이브러리의 소비자가 다른 버전의 종속성 등을 사용하는 경우 제어할 수 없습니다. 따라서 라이브러리 관리자가 이를 관리할 수 있는 실행 가능한 방법이 없다는 데 동의합니다.

그러나 여기의 목표는 아마도 훨씬 더 작은 범위일 것입니다. 특히 라이브러리 유지 관리자의 목표는 다음과 같습니다(대략 동등함).

1. CI를 두 번 실행하면 동일한 결과를 얻을 수 있습니다(네트워크 문제에도 불구하고!).
2. Docker/etc를 실행하는 것을 의미하더라도 CI에서 관찰한 동작을 로컬에서 다시 생성(따라서 디버그)할 수 있습니다. 장소 상에서.
3. 소비자에게 "내 라이브러리는 종속성 버전 X, Y, Z에서 예상대로 작동합니다"라고 자신 있게 말할 수 있습니다.

이 세 가지 중 하나라도 충족되지 않으면 품질 관리에 반대되는 것입니다.

예, 소비자에게 Python 변형 A, B 및 C를 지원하도록 보장하고 하나의 잠금 파일(등)이 잘리지 않을 정도로 다르게 동작한다면 세 개의 잠금 파일(또는 무엇이든).

그러나 실제로 얼마나 쉬운지 알기 위해 Pipenv를 충분히 사용하지 않았습니다.

현재 CI 시스템에 대한 몇 가지 라이브러리 프로젝트에도 Pipfile 추가하는 것을 고려하고 있습니다.

회사 전체의 보안 지침을 준수하기 위해 종속성 잠금(+해싱)이 절대적으로 필요하며 현재 공식적으로 지원되는 버전이 하나만 있기 때문에 다른 Python 버전으로 테스트할 필요가 없습니다. 그리고 pipenv가 virtualenv를 포함한 로컬 개발 환경 설정을 단순화한다는 사실은 좋은 부작용입니다.

그리고 당신이 얻는 것은 다른 컨텍스트에 설치될 라이브러리이며(예: 1주일 후에 표준 설치는 업그레이드된 종속성을 선택합니다) 사실에서 아무 것도 얻지 못하는 Pipfile.lock 를 사용했습니다. 현재는 사용되지 않습니다.

이것은 보편적으로 사실이 아닙니다. 엔터프라이즈 소프트웨어의 세계에는 여전히 공식적으로 지원되는 매우 구체적인 환경이 있으며 종속성의 보안 문제로 인해 고객이 종속성을 업데이트하는 대신 제품이 업데이트됩니다.

(예, 여기에서 응용 프로그램이 아니라 라이브러리에 대해 이야기하고 있습니다 ...)

@Moritz90 귀하의 시나리오는 엔터프라이즈 환경의 python 라이브러리에 대한 것이며 pipenv 가 훨씬 더 결정적인 환경이기 때문에 도움이 될 수 있습니다.

내 설명은 컨텍스트가 훨씬 더 가변적인 flask , request , maya 등과 같은 일반적인 파이썬 라이브러리를 목표로 합니다. maya 에서 몇 가지 문제를 해결하려고 하면 많은 경우 pipenv 사용하면 실제 문제(일반적으로 일반적으로 감지되는 문제를 숨김)를 발생시키는 반면 많은 추가 또는 추가를 제공하지 않는다는 사실을 알게 되어 좌절감을 느꼈습니다. 값.

결정적 빌드를 얻는 것은 좋은 일이지만 비용이 발생합니다. 그리고 잘못하면 더 낮은 품질의 결과에 대해 추가 비용을 지불할 수 있습니다. 이것이 제가 방지하고 싶었던 것입니다.

나는 이것이 우리가 빌드가 절대적으로 결정적인 것을 원하지 않는 경우 중 하나라고 주장하고 싶습니다. == 종속성을 고정하지 않으면 기본적으로 여러 버전에 대한 지원을 유지하기로 약속하고 라이브러리를 그런 식으로 설계해야 합니다. CI에서 빌드를 깨는 종속성 업그레이드는 라이브러리의 버그를 노출하기 때문에 실제로 좋은 것입니다. 완전히 결정적인 종속성(Pipenv에서 관리)은 이를 마스킹합니다. 당신이 그것을 원할 때 결정적일 수 있다는 것은 여전히 ​​유익할 것입니다. 그것은 일반적으로 최선이 아닙니다.

@uranusjr - 물론입니다. 나는 욕망이 "비결정적 빌드"라면 상단의 조언이 의미가 있을 수 있다는 데 동의합니다. 사실, 이것은 거의 논리적으로 동등하며 훨씬 더 간결하게 말할 수 있습니다. "결정론적 빌드를 원하지 않으면 결정론적 빌드를 보장하는 것이 목적인 도구( pipenv )를 사용하지 마십시오." 😄.

그러나 일반적으로 바람직한 목표는 아닙니다.

@tsiq-oliverc 멋진 범위 정의 - 집중 토론을 지원합니다. 한 가지 요구 사항을 더 추가하겠습니다 . CI 결정론은 테스트된 라이브러리 내에서 가능한 문제를 숨기지 않아야 합니다.

Pipenv.lock 를 사용하고 이를 기반으로 virtualenv를 만들고 라이브러리의 CI 테스트를 실행하면 라이브러리가 수행해야 하는 기능의 일부인 적절한 종속성을 설치했습니다. 이와 관련하여 라이브러리가 어떻게든 손상되면 사전 설치된 환경에서 이 문제를 숨길 수 있습니다.

나에게는 CI를 결정적인 방식으로 실행하는 것보다 라이브러리 내에서 문제를 감지하는 것이 더 중요해 보입니다. 두 가지를 모두 수행할 수 있는 방법이 있다면(예: 결정론도 지원할 수 있는 비공개 pypi 인덱스 뒤에서 테스트 실행) 문제가 없지만 충돌이 있는 경우 우선 순위가 있습니다.

오해하지 마세요. 비결정적 빌드를 실행하고 싶은 마음

@vlcinsky 물론입니다. 업데이트된 문서에도 이를 반영하도록 제 경험을 공유하고 싶었습니다. 현재 문서는 장단점을 잘 설명하고 있습니다.

라이브러리의 경우 setup.py의 install_requires를 통해 추상 종속성을 정의합니다. [...]
응용 프로그램의 경우 Pipfile에서 종속성과 이를 가져올 위치를 정의하고 이 파일을 사용하여 Pipfile.lock에서 구체적인 종속성 세트를 업데이트합니다. [...]
물론 Pipfile 및 pipenv는 개발 또는 테스트 환경을 정의하는 데 사용할 수 있으므로 라이브러리 개발자에게 여전히 유용합니다.
물론 라이브러리와 응용 프로그램의 구분이 명확하지 않은 프로젝트도 있습니다.

(제 경우에 해당되는 부분을 강조 표시했습니다.)

그대로 유지되도록 하고 싶습니다. 귀하의 원본 게시물에는 PyPI에 게시될 오픈 소스 프로젝트에 대한 면책 ​​조항 없이 포괄적인 설명이 너무 많이 포함되어 있다고 생각합니다.

@Moritz90 전적으로 동의합니다. 나는 그 초점을 강조하려고 노력했지만 더 눈에 띄게 만들 수 있습니다.

@Moritz90 귀하의 의견을 반영하여 소개글을 추가했습니다.

@vlcinsky - 말이 됩니다. 나는 당신이 명시적으로 비결정적 빌드를 원하지 않는다는 것을 이해하지만, 당신 이 원하는 것과 불가피하게 동등하다고 생각합니다(즉, 업스트림 종속성이 업데이트될 때 문제를 포착하기 위해).

큰 소리로 생각해보면 이 상충되는 두 가지 목표를 해결하는 가장 좋은 방법은 무엇입니까? 한 가지 가능성은 2단계 CI 프로세스를 갖는 것입니다.

1. 결정적 단계. 리포지토리에서 Pipfile.lock 를 활용하므로 완전히 재현 가능합니다.
2. 비결정적 단계. pipenv update 를 실행한 다음 테스트를 실행하여 모든 종속성의 최신 항목을 가져옵니다(기본적으로 잠금 파일이 없는 동작과 동일하다고 생각합니까?).

@tsiq-oliverc 결정적 빌드를 얻으려면 다음 설정을 생각합니다.

• pypi 캐시 작업 빌드: 옛날에 한 번 실행하여 pypi 인덱스 캐시 형식(파일 디렉토리 또는 이와 유사한 것)을 생성합니다.
• 라이브러리 테스트 작업: pypi 캐시를 사용하지만 pipenv

pipenv 를 사용하여 설치하는 것은 라이브러리 자체를 설치하는 것과 유사하지만 작업을 수행하는 코드가 다르기 때문에 확실히 다릅니다.

pypi 캐시 작업 빌드

$ git clone <repo_url> <project_dir>
$ cd <project_dir>
$ pip install pipenv
$ $ # clean pypi cache and make it ready to cache somehow - not described here
$ pipenv install -e .[test]
$ # if we need extra testing packages in pipenv
$ pipenv install <extra_test_packages>
$ # record current requirements expressed in `Pipfile.lock`
$ pipenv lock
$ # if needed, record the `Pipfile.lock` somewhere

이러한 작업의 출력은 다음과 같습니다.

• 기록된 종속성으로 Pipfile.lock (개발자가 환경을 쉽게 재현하는 데 도움이 될 수 있음)
• 미리 채워진 로컬 pypi 캐시

라이브러리 테스트 작업

단계가 있습니다:

• 로컬 pypi 캐시만 사용하여 tox , pip 등을 강제 실행하도록 환경을 구성합니다.
• CI 테스트 실행( pipenv )

우리가 얻는 것

• 라이브러리는 결정적 환경에서 테스트됩니다.
• 라이브러리는 다음을 포함하여 테스트됩니다. 자체적으로 설치하는 기능입니다.
• Pipfile.lock 는 라이브러리를 설치하는 데 사용된 pypi 패키지를 기록합니다. 개발자 사이트에서 환경을 재현하는 데 사용할 수 있습니다.
• (외부일 수도 있는) pypi에서 업그레이드된 패키지에 대한 적응은 간단하고("pypi 캐시 작업 빌드 다시 실행)" 제어된 방식으로 수행됩니다(pypi의 내용은 해시를 포함하여 기록됨)

또 다른 장점은 이 설정에서 개발자가 Pipfile 또는 Pipfile.lock 유지 관리할 필요가 없다는 것입니다. 또한 다른 컨텍스트에서 테스트를 실행하는 것은 항상 동일합니다( Pipfile.lock 는 항상 주어진 컨텍스트에서 다시 빌드됩니다).

아직 부족한 것(그리고 할 수 있는 것)

pypi 캐시는 약간의 연구가 필요한 부분입니다. 간단한 디렉토리로 충분하고 pipenv 가 이미 도움이 될 것입니다. 문제 #1731이 누락된 부분일 수 있습니다.

종속성 해결을 수행하는 패키지로서 우리의 많은 테스트는 결정적 빌드에 의존합니다. 즉, 알려진 내용을 취하고 해결된 그래프를 기대합니다. 이를 위해 pytest-pypi 를 사용합니다.

이 주제에 대한 활발한 토론을 좋아하십시오. 뉘앙스가 중요하다고 생각하며 항상 알려진 종속성과 고정되지 않은 종속성에 대해 테스트해야 합니다.

항상 알려진 종속성과 고정되지 않은 종속성에 대해 테스트해야 합니다.

나는 이 제안을 두 번째로 한다. 재생 가능한 빌드에 대해 항상 명시적인 "알려진 양호한 상태"를 유지하고 업데이트가 새로운 부/버그 수정 버전도 작동하는지 확인하는 것 외에도 업데이트가 중단되는 경우 디버깅을 단순화하는 것이 좋습니다.

(내 개인적인 의견으로는 이상적인 상황은 패키지 관리자가 기본적으로 최신 부 버전을 설치하여 라이브러리가 테스트한 구체적인 종속성 버전을 항상 지정할 수 있도록 하는 것이지만, 이는 매우 논란의 여지가 많은 의견이며 모든 사람이 필요하다는 것을 알고 있습니다. semver를 따르십시오.)

@Moritz90 @techalchemy @uranusjr @tsiq-oliverc

다음은 이전 토론의 요약입니다.

특정 문제 및 제안된 솔루션

많은 실행 컨텍스트 - 누가 Pipfile.lock 파일을 유지해야 합니까?

지원되는 각 OS 및 Python 인터프리터는 가능한 실행 컨텍스트의 매트릭스에 기여합니다.

예를 들어 Flask는 다음을 지원합니다(최소한 저장소에서 볼 수 있는 CI 항목).

• OS Windows(python 2.7 및 Python 3.6)
• Linux(파이썬 2.7, 3.4, 3.5, 3.6, 야간, pypi)
• OSX(py - 더 많은 버전이 있는지 확실하지 않음)

다를 수 있는 9개의 다른 실행 컨텍스트를 만듭니다.

각 실행 컨텍스트는 서로 다른 Pipfile.lock 가질 수 있습니다.

누가 그들을 유지할 것인가?

옵션은 다음과 같습니다.

• 개발자가 수동으로 수행하도록 허용(NO WAY)
• 메인 개발 플랫폼을 위해 단 하나의 Pipfile.lock 유지(어떤 플랫폼이 무시되기를 좋아합니까?)
• CI를 통한 자동 생성(예)

제안: CI가 pipenv install -e . 파일을 생성하도록 합니다. 저장소에 포함하지 말고 개발자가 자동화된 빌드의 결과로 적절한 Pipfile.lock 를 선택하도록 도와주세요.

개발자에게는 예측 가능한 환경이 필요합니다.

pypi에 대한 종속성 변경으로 인해 발생할 수 있는 문제를 수정할 때 개발자는 실패한 테스트에서 환경을 재현하기 위한 간단한 수단이 필요할 수 있습니다.

제안:

• 많은 패키지의 경우 pypi 종속성 변경이 너무 드물기 때문에 실제 문제가 아닙니다.
• 자체적으로 환경을 수정하기 위해 개발자는 pipenv install -e . 다음에 pipenv lock Pipfile.lock 를 생성할 수 있습니다.
• 실패한 테스트에서 환경을 복제하기 위해 개발자는 실패한 테스트에서 Pipfile.lock 를 선택합니다.
• 할 일: Pipfile.lock 에 tox.ini Pipfile.lock 를 적용하는 방법의 예를 보여줍니다.

CI는 깨진 setup.py 밝혀야 합니다.

setup.py 라이브러리가 손상될 수 있으며( install_requires 종속성 누락, 버전 지정자 누락 등) CI 테스트는 이러한 문제를 숨기지 않아야 합니다(자체적으로 생략된 종속성을 사전 설치하여).

제안:

• pipenv install -e . 를 신뢰하여 일반 설치와 동일한 결과를 제공합니다(현재 몇 가지 문제가 있음).
• 일반 설치 테스트( pipenv 제외)를 실행하고 결과 pip freeze 출력이 pipenv 의해 설치된 항목의 하위 집합임을 비교할 수 있습니다.

업데이트된 pypi 종속성은 문제를 일으킬 수 있으며 CI는 이러한 추적을 감지합니다.

일부 종속성 업데이트는 이를 사용하는 라이브러리를 중단시킬 수 있습니다. CI는 이러한 문제에 대한 실패를 감지해야 합니다.

제안:

• 고정 해제된 버전에 대해 하나 이상의 테스트를 실행해야 합니다.
• CI가 항상 새로운 Pipfile.lock 생성한다면 이것은 문제가 되지 않습니다(어쨌든 고정 해제 모드에서 실행하기 때문에)

다양한 라이브러리 유형에 대한 CI 모드

제안된 모든 모드에서 pipenv 파일을 저장소에 보관하지 않으려고 노력했습니다. 개발자가 이 복잡한 작업(자동화!!!)을 유지 관리하지 못하도록 저장합니다.

내 원본 텍스트와 달리 두 번째 및 세 번째 모드는 CI 스크립트에서 pipenv 를 사용합니다.

모드: 달려라, 포레스트, 달려라!

자주 변경되지 않는 더 적은 수의 종속성을 가진 간단한 패키지입니다.

pipenv 시대 이전처럼 실행하고 우리에게 간단하게 유지하십시오.

종속성이 문제를 수정하기 쉽게 만들고 CI를 더 복잡하게 만드는 것을 정당화하지 않는 드문 경우입니다.

모드: 생성 및 봉인

CI 테스트가 실행될 때마다 현재 사용되는 환경을 완전히 설명하는 새로운 Pipfile.lock 를 생성합니다.

Pipfile.lock 는 CI 인공물이 됩니다.

일이 잘못되면 개발자는 깨진 빌드에서 Pipfile.lock 를 선택하고 로컬에 적용하고 테스트 및 수정을 수행할 수 있습니다.

누군가 배포하려는 경우 마지막으로 성공한 빌드의 Pipfile.lock 를 사용할 수 있습니다.

모드: 빙하기

의존성을 변경하는 것이 실제 문제일 때 CI는 한 번 Pipfile.lock 생성하여 일정 기간(한 달?) 동안 계속 사용합니다.

이것은 적어도 두 개의 다른 작업이 있어야 하므로 CI 설정을 더 어렵게 만듭니다(하나는 Pipfile.lock , 다른 하나는 이를 적용하고 테스트에서 사용).

경고: Pipfile.lock 도 현재 업데이트되어야 합니다. setup.py 는 종속성을 변경합니다.

빙하기에는 동결 상태를 무시하고 고정되지 않은 버전을 확인하는 Scrat 다람쥐 유형의 테스트가 필요합니다.

맺음말

보시다시피, 결정론과 복잡성은 모드별로 증가합니다.

내 제안은 다음과 같습니다.

• 간단하게 시작하십시오("실행, 포레스트, 실행"). 효율성과 속도를 얻을 수 있습니다.
• 종속성 변경으로 인해 상황이 너무 복잡해지면 "생성 및 봉인"으로 이동하십시오. 로컬 환경에서 반복성을 얻을 수 있습니다.
• 상황이 정말 안 좋은 경우 "Ice Age" 모드로 이동하십시오. (일시적) 결정성을 얻습니다.

모든 이익에는 비용이 듭니다.

여기의 목표가 문서의 조언을 업데이트하는 것이라면 솔직히 "선택의 여지가 없을 때까지 기본적으로 모범 사례(재현 가능한 빌드)를 따르십시오"와 극적으로 다른 말을 하는 것은 무책임하게 느껴집니다.

@vlcinsky "모드: 생성 및 봉인"이라는 제목 아래에서 마지막으로 성공한 Pipfile.lock 는 예를 들어 Jenkins 아티팩트로 선언하여 항상 주위에 보관해야 한다고 언급하는 것이 합리적일 수 있습니다. 이러한 변경을 통해 대부분의 프로젝트에 해당 설정을 권장하는 것이 좋습니다. @tsiq-oliverc와 마찬가지로 첫 번째 모드를 권장하지 않습니다.

생각하면 할수록 이 문서가 라이브러리를 개발 중이더라도 CI 빌드에 pipenv 를 사용하는 것이 좋은 아이디어인 이유에 대한 섹션이 될 것 같습니다.

@tsiq-oliverc 대다수의 일반 파이썬 패키지는 "실행, 포레스트, 실행" 모드에 있습니다. 나는 tox 및 pytest 를 도입하는 데 있어 이러한 패키지 중 몇 개를 도왔습니다. 왜냐하면 그것이 주어진 패키지 품질에 기여할 것이라고 생각했고 어떻게 하면 잘 할 수 있는지에 대한 명확한 아이디어가 있었기 때문입니다.

이제 또 다른 훌륭한 도구가 있으며 일반적인 파이썬 프로젝트에서 pipenv 적절하게 사용하여 품질에 기여하는 방법이 궁금합니다. 나는 정당하고 따르기 쉬운 하나 또는 두 개의 잘 작동하는 레시피를 찾고 싶습니다.

Flask 프로젝트에 뭐라고 말하겠습니까?

1. 선택의 여지가 없을 때까지 기본적으로 모범 사례(재현 가능한 빌드)를 따르시겠습니까?
2. Pipfile.lock 파일 9개를 추가하고 업데이트 정책을 설정하시겠습니까?
3. Travis와 Appveyor가 Ice Age 모드에 따라 2단계 방식으로 작동하도록 CI 스크립트를 리팩터링하시겠습니까?
4. 누군가가 자신의 컴퓨터에서 실패한 테스트를 재현해야 하는 경우에 대비하여 Pipfile.lock 인공물을 생성하도록 Travis 및 Appveyor용 CI 스크립트를 수정하시겠습니까?
5. "Flask에 감사드립니다."라는 말 외에는 코멘트가 없습니다.

목표는 기능적인 작업 스타일을 찾는 것입니다. 문서로 끝나는 경우 좋고, 그렇지 않은 경우 문제가 없습니다.

@vlcinsky 나는 (1)과 (4)가 그러한 프로젝트에 대한 권장 사항이어야 한다고 말하고 싶습니다. 기존 Pipfile.lock 가 없으면 빌드에 사용된 버전을 미리 알 수 없지만(회사 환경 외부에서는 괜찮음) 잠금 파일을 생성하고 보관하면 여전히 재현 가능한 결과를 얻을 수 있습니다. 빌드 중.

편집 : 내 권장 사항의 tl;dr 버전은 다음과 같습니다.

• 라이브러리를 개발하든 애플리케이션을 개발하든 상관없이 빌드를 재현할 수 있는지 항상 확인하십시오. pipenv 는 이 목표를 달성하는 데 도움이 될 수 있습니다.
• 애플리케이션을 개발하는 경우 Pipfile.lock 를 리포지토리에 커밋하고 배포에 사용합니다. (이는 이미 기존 문서에서 다룹니다.)
• 오픈 소스 라이브러리를 개발하는 경우 CI 빌드에서 즉시 Pipfile.lock 를 생성하고 나중에 사용할 수 있도록 보관하십시오.
• 라이브러리를 개발 중이고 제한적인 기업 환경에서 작업하는 경우 적절한 수의 잠금 파일을 유지하고 CI 빌드에서 사용하십시오.

(물론 실제 문서에는 좀 더 자세한 내용과 예제가 있어야 합니다.)

@ Moritz90 당신이 제안한대로 "생성 및 봉인"을 수정했습니다.

Re (1): 말하기 쉽고, 더 구체적이지 않고는 실행할 수 없습니다.

Re(4): 예, "생성 및 봉인"이 가장 실현 가능한 모드라고 생각합니다. 그러나 Flask의 경우 감히 하지 않을 것입니다(적어도 현재로서는).

기업 환경에 기존 Pipfile.lock 존재: (반)수동 또는 자동으로 어떻게든 생성되어야 합니다. 기업 환경에서는 공용 pypi에서 직접 설치하지 않고 일부 개인용 pypi를 사용하고 승인된 패키지만 제공합니다( devpi-server 는 여러 인덱스, 게시된 패키지의 제어된 변동성, 외부에 대한 승인과 같은 훌륭한 서비스를 제공합니다. 패키지 등) Pipfile.lock 빌드 프로세스가 이러한 환경에서 실행되면 승인된 것만 사용할 수 있으므로 새 버전이 거기에 나타나려면 누군가 일어나 승인해야 합니다. 다음 CI 빌드는 문제가 발생하지 않는지 테스트합니다. 그리고 pipenv check 사용하면 보안 문제 테스트도 자동화할 수 있습니다.

그런 워크플로는 누군가가 (반)수동으로 만드는 것보다 더 안전할 것이라고 생각합니다. 그러나 기업 환경에 대한 나의 지식은 매우 제한적입니다.

안녕하세요 pipenv팀입니다. 나는 이 텍스트에서 많은 것을 공유합니다. 이것은 모든 개발자가 라이브러리를 개발할 때 Pipfile/pipenv의 한계를 더 잘 이해하는 데 많은 도움이 됩니다. 공식 pipenv 문서에 통합된 이 텍스트 또는 이 텍스트의 일부를 보고 싶습니다.

논의하고 싶은 다음 수정안이 있습니다.

완전히 재사용할 수 있고 내부 pypi 등에 게시된 내부 Python 패키지의 경우, 심지어 내 자신의 Python 패키지(예: cfgtree , txrwlock , pipenv-to-requirements )에 대해서도 이미 알고 있거나 사용하고 있는 패키지를 사용합니다. , 이러한 세부 사항을 추상화하고 Python 개발자의 삶을 더 쉽게 만듭니다: PBR.
PBR 이것은 기본적 읽고 requirements.txt 에 배포 패키지의 루트 폴더에과 주입 발견 install_requires 의 setup.py . 개발자는 느슨한 종속성 선언으로 requirements.txt 를 유지하기 Pipfile 이 공식적으로 PBR 내부에 통합될 때까지 requirements.txt 에서 Pipfile requirements.txt 를 자동으로 생성하는 pipenv-to-requirements 를 사용해야 동기화되고 둘 다 커밋됩니다. 소스에 있고 PBR은 배포 패키지가 빌드된 후 올바르게 주입을 수행합니다. pipenv 를 사용하여 requirements.txt 를 생성할 수 있다고 생각합니다.

나는 작업 Pipfile의지지 가 읽을 수 그래서, PBR에 대한 Pipfile (그리고 잠금 파일을)과로 주입 install_requires 이 함께하는 것처럼 requirements.txt .

다른 유사한 패키지가 존재하는지 여부는 모르겠습니다. 사람들이 원하지 않는 다른 작업도 수행하기 때문입니다(git history 버전, AUTHORS 및 ChangLog 자동 생성).

그러나 결국에는 Python 라이브러리의 버전 관리를 작성, 유지 관리 및 처리하는 것이 훨씬 더 쉽다고 느끼므로 이 경험을 공유하지 않는 것이 슬플 것입니다. 나는 그것을 우리 회사에서 최신 파이썬 라이브러리를 작성하는 "권장" 방법으로 홍보하고 있습니다.

나는 그것이 라이브러리와 pipenv에 대한 모든 어려움에 대해 "속임수"와 같다고 생각하지만 결국 작업이 완료되고 개발자는 지금까지 그것을 사용하게되어 기쁩니다. python 교육의 일부로 회사의 새로운 python 개발자에게 제공하고 있습니다. 먼저 install_requires 수동으로 유지 관리하는 python 라이브러리를 작성한 다음 PBR 로 전환하여 더 쉬워지는 방법( 솔직히 저는 올바른 semver 버전 태그를 자동으로 생성하는 pbr의 시맨틱 커밋 기능 의 팬입니다.

라이브러리에 대한 전용 파일을 사용하여 라이브러리 종속성을 선언하는 이유 중 일부는 readthedocs 또는 pyup과 같은 도구를 사용할 수 있기 때문입니다(pyup이 애플리케이션에 연결될 때 더 의미가 있더라도).

나는 반드시 이 방법을 파이썬 패키지를 수행하는 "표준" 방법으로 홍보하고 싶지는 않습니다. 실제로는 "OpenStack" 방법이지만 제 경험을 공유하고 다른 사람들이 유사하거나 모순된 경험을 가지고 있다면 그들의 의견을 듣고 내 관점을 업데이트하게 되어 기쁩니다.

팀, 문서에 있는 일종의 "커뮤니티" 섹션에 대해 어떻게 생각하세요? 나 같은 사용자가 pipenv 팀의 전체 승인 없이도 그가 pipenv를 사용하는 방법에 대한 경험을 공유할 수 있도록?

추신: 이 스레드를 더럽히고 싶지 않다면 이 문제를 전용 문제로 이동할 수 있습니다.

@vlcinsky (1)는 실행하기가 매우 쉽습니다. 잠금 파일을 저장소에 넣으십시오.

제 생각에는 이 기본 전략이 더 이상 충분하지 않으면 구체적인 조언을 제공하는 것이 불가능합니다. 그것은 확실히 사실이지만 특정 문제가 사례별로 다를 수 있기 때문입니다.

다른 식으로 말하면 솔루션은 CI 워크플로에서 제공하기를 원하는 추가 보장에 따라 달라집니다.

@gsemet 그거 알아? 지난 2년 동안 만든 모든 파이썬 패키지는 pbr 기반으로 합니다. 정말 훌륭합니다. 그리고 가능한 한 pbr에서 Pipfile을 지원하려는 귀하의 시도를 따릅니다(일부 엄지손가락, 투표 등).

이 문제의 경우(일반 파이썬 라이브러리에 대한 pipenv 패턴 및 안티패턴 검색) 두 가지 이유로 의도적으로 pbr 를 생략했습니다.

• 그것은 개념적 토론을 더 복잡하게 만들 것입니다.
• 어떤 사람들은 다른 이유로 pbr 를 좋아하지 않으며(당신이 언급했습니다) 토론을 방해할 것입니다.

한편, 나는 pbr 애호가를 위한 당신의 레시피를 정말 기대하고 있습니다. 나는 그것을 읽을 것이다.

@tsiq-oliverc 당신은 못을 박았습니다: 당신의 잠금 파일을 당신의 저장소에 넣으세요

이것이 바로 제가 이 문제를 시작하게 된 동기입니다. 이 문제의 시작 부분을 다시 읽으면 Pipfile.lock 추가하면 CI 테스트가 중단될 수 있는 몇 가지 사례에 대한 설명을 찾을 수 있습니다(빌드 실행 중단 또는 문제 숨기기, 그렇지 않으면 감지될 수 있음 또는 잘못된 종속성 설치 주어진 컨텍스트에 대해...).

이 작업이 제대로 수행되는 저장소(일반 파이썬 라이브러리)를 보여주시면 기쁠 것입니다. 또는 어떤 위험이 있는지 또는 어떤 일이 완료되지 않았는지 보여주고 싶습니다.

멋있는 ! 나는 또한 이 쿠키 커터를 유지

@vlcinsky 맞습니다. 그래서 구체적인 문제를 열거하고 그에 대한 해결책을 찾아봅시다 😄 (Pipenv를 사용하는 고품질 라이브러리는 모르지만 주로 내가 보지 않았기 때문입니다.)

내가 말할 수있는 한, 다음은 원래 게시물의 특정 증상입니다.

• 깨진 setup.py 종속성 숨기기. 이것은 문제가 아닌 것처럼 들립니다 - pipenv install -e . , 맞습니까?
• 다른 파이썬 버전이나 다른 OS에서는 종속성이 유효하지 않을 수 있습니다. 이것이 문제 가 될 알 수 있지만 실제로 이것이 중요한 부분에 대한 구체적인 예를 제공할 수 있습니까? (잠금 파일의 컨텍스트에서)
• 다른 라이브러리가 업데이트되고 라이브러리 내에서 사용할 수 있을 때 개발자는 업데이트해야 합니다. 그들은 그렇게 하도록 강요 받지 않습니다. 라이브러리가 종속성의 버전 n 이 아닌 버전 n+1 에 대해 작동한다는 보장을 제공하려는 경우 그렇게 합니다. 그러나 두 세계의 장점을 모두 제공하는 대안을 이미 제안 했습니다.
• Tox와 경쟁합니다. 저는 톡스에 대해 전혀 모릅니다. 하지만 네, 두 개의 도구를 동시에 사용하여 종속성을 관리하는 것은 재앙의 처방처럼 들립니다. 나는 그 특정 작업에 대해 더 나은 것을 사용한다고 말하고 싶습니다.
• Pipenv가 실패합니다. 이것은 또 다른 문제가 아닌 것처럼 들립니다. Pipenv 버전을 고정할 수 있습니다(Docker 이미지, Pip 버전 등을 고정하는 것처럼 현재 솔루션입니다).

@tsiq-oliverc 귀하의 의견은 저에게 영감을 주었고 제안된 솔루션의 재현 가능성을 높이는 데 기여했다는 것을 알고 있습니다.

다음은 반복성을 보장하기 위해 잠금 파일( Pipfile.lock )을 repo에 넣는 제안과 관련이 있습니다.

다시 깨진 setup.py 종속성을 숨깁니다. . pipenv install -e . 은 내가 제안한 것을 따르지만 이것은 Pipfile.lock 사용법이 아니라 그것을 (재) 생성하는 방법입니다. 누군가 Pipenv.lock 보관하고 패키지를 설치하기 전에 virtualenv를 만드는 데 사용하면 문제가 있는 것입니다.

re 의존성은 다른 파이썬 버전이나 다른 OS에서 유효하지 않을 수 있습니다 . 예는 많습니다. Python 2.7용으로 설치된 doit 는 최신 버전이 Python 2.x에 대한 지원을 중단했으므로 이전 버전이어야 합니다. watchdog 종속성은 플랫폼 종속 라이브러리가 필요합니다. Linux에서는 inotify, Windows에서는 다른 것, OSX에서는 다른 것입니다. 내 전 고객은 "이것은 절대 일어나지 않을 것입니다"라고 말하곤 했으며 상황의 50%에서 2주 이내에 발생했습니다. 이것은 CI 스크립트에 대한 모범 사례가 아닙니다.

re 개발자는 업데이트해야 합니다. .. 15명의 기여자가 있는 오픈 소스 라이브러리를 상상해 보십시오. 초보자나 피곤한 코어 개발자가 Pipfile.lock 를 재생성하는 것을 잊는 것은 매우 쉽습니다. 의 예 : maya 나는 재생하도록 요청 받았다 패키지 Pipfile.lock 새로운 의존성에 추가로 setup.py . 그게 꼭 필요한 일이었나요? 내가 제대로 업데이트 했습니까? 지원되는 모든 실행 컨텍스트에 대해 업데이트했습니까? 대답은 아니오, 확실하지 않음, 아니오입니다. 어쨌든, 귀하의 제안에 감사드립니다(귀하의 의견 옆에 설명된 솔루션에 영감을 주었습니다).

re Competing with tox : Tox를 사용하면 여러 가상 환경을 만들고 그 안에서 테스트 실행을 자동화할 수 있습니다. 일반적인 tox.ini 는 python 2.7, 3.4, 3.5, 3.6 및 기타 필요한 모든 가상 환경을 정의하고 여기에 패키지를 설치하고 테스트 스위트를 실행할 수 있습니다. 그것은 진지한 테스터의 확립 된 powertool입니다. pipenv 는 이 목적을 위한 도구가 아니지만 필요한 것을 설치하는 데 방해가 될 수 있습니다. 어떤 면에서 나는 당신의 조언을 따랐고 가능하면 pipenv 보다 우수한 도구(tox)를 사용할 것을 제안했습니다.

다시 Pipenv가 실패합니다. 이것은 정말 불행한 일입니다. 로컬 호스트에서 잘 실행되는 CI 테스트(tox 기반)가 있었지만 Travis를 통해 실행할 때 pipenv 문제로 인해 실패했습니다. 지금 사용하려는 경우 수정 사항이 릴리스될 때까지 고정이 도움이 되지 않습니다. 그러나 이것이 진행되는 방식입니다. 나는 기다릴 것입니다.

내 원래 게시물의 일부는 업데이트되어야 하는 것처럼 보입니다. CI 스크립트에서 pipenv 를 사용하면 적절한 위치에 있습니다(나중에 사용할 수 있도록 virtualenv 구성을 "봉인").

@tsiq-oliverc "잘 알려진" 버전과 최신 버전 모두에 대해 테스트하라는 귀하의 제안이 처음에는 마음에 들었지만, 생각할수록 노력을 정당화하기가 점점 더 어려워지고 있습니다. 둘 중 하나가 아니라 둘 중 하나를 선택해야 한다고 생각합니다.

얻을 수 있는 유일한 이점은 오류가 종속성 업데이트 또는 코드 변경으로 인해 발생했는지 여부를 즉시 알 수 있다는 것입니다. 그러나 별도의 커밋을 수행하거나(잠긴 종속성을 수동으로 업데이트할 때) 또는 성공적인 빌드에 의해 생성된 최신 잠금 파일로 버그를 재현하려고 시도하면(항상 최신 버전을 사용할 때) 동일한 결과를 얻을 수 있습니다. 그리고 제한된 환경에서는 어쨌든 "업데이트"할 수 없습니다...

@vlcinsky 환경 간의 차이점에 대한 귀하의 일반적인 요점에는 동의하지만 "구성당 하나의 잠금 파일" 인수는 나에게 밀짚맨처럼 들립니다. 실제로는 적어도 일부 환경 간에 잠금 파일을 공유할 수 있습니다.

아직 아무도 대답하지 않은 미해결 질문 중 하나는 서로 다른 환경에서 테스트하고 종속성을 잠글 필요가 있는 경우를 처리하는 방법입니다. 나는 tox 대해 그것이 존재한다는 것 외에는 아무것도 모른다는 것을 인정해야 하지만 tox 와 pipenv 사이에 일종의 접착제가 필요한 것처럼 보입니다. 그것은 어떻게 든이 문제를 해결합니다.

@모리츠90

빨대를 만나다

Pipfile.lock 의 너무 많은 변종을 밀짚맨으로 사용하는 경우(다른 사람들을 내 분야에서 제외하기 위해):

플라스크

나는 flask 프로젝트(매우 성숙한 것으로 간주)를 취하고 독소 테스트를 실행했습니다.

여기에 테스트된 변형 목록이 표시됩니다(Linux에서 로컬로, Windows 및 OSX가 동일한 테스트 세트를 수행하지만 다른 환경이 발생할 수 있으므로 3을 곱합니다).

하나의 OS에는 16개의 다른 테스트 실행이 있습니다. 그 중 5개는 설치하지 않았기 때문에 실패했습니다(괜찮습니다). 하나는 문서 작성(중요한 라이브러리가 필요함)을 다루고 있고 다른 하나는 커버리지(가져오기 가능한 라이브러리도 필요함)를 다루고 있습니다. ):

  coverage-report: commands succeeded
  docs-html: commands succeeded
  py27-devel: commands succeeded
  py27-lowest: commands succeeded
  py27-simplejson: commands succeeded
  py27: commands succeeded
  py35: commands succeeded
  py36-devel: commands succeeded
  py36-lowest: commands succeeded
  py36-simplejson: commands succeeded
  py36: commands succeeded
ERROR:   py34: InterpreterNotFound: python3.4
ERROR:   pypy-devel: InterpreterNotFound: pypy
ERROR:   pypy-lowest: InterpreterNotFound: pypy
ERROR:   pypy-simplejson: InterpreterNotFound: pypy
ERROR:   pypy: InterpreterNotFound: pypy

생성된 각 virtualenvs에 대해 pip freeze > {venv_name}.txt requirements.txt 파일을 만들었습니다.

그런 다음 해시 값에 따라 정렬된 파일에 대해 계산된 해시가 있으므로 모두 동일하게 그룹화됩니다. 여기 빨대가 온다:

b231a4cc8f30e3fd1ca0bfb0397c4918f5ab5ec3e56575c15920809705eb815e  py35.txt
b231a4cc8f30e3fd1ca0bfb0397c4918f5ab5ec3e56575c15920809705eb815e  py36.txt
cdf69aa2a87ffd0291ea65265a7714cc8c417805d613701af7b22c8ff2b5c0e4  py27-devel.txt
dfe27df6451f10a825f4a82dfe5bd58bd91c7e515240e1b102ffe46b4c358cdf  py36-simplejson.txt
e48cd24ea944fc9d8472d989ef0094bf42eb55cc28d7b59ee00ddcbee66ea69f  py36-lowest.txt
f8c745d16a20390873d146ccb50cf5689deb01aad6d157b77be203b407e6195d  py36-devel.txt
053e107ac856bc8845a1c8095aff6737dfb5d7718b081432f7a67f2125dc87ef  docs-html.txt
45b90aa0885182b883b16cb61091f754b2d889036c94eae0f49953aa6435ece5  py27-simplejson.txt
48bd0f6e66a6374a56b9c306e1c14217d224f9d42490328076993ebf490d61b5  coverage-report.txt
564580dad87c793c207a7cc6692554133e21a65fd4dd6fc964e5f819f9ab249c  py27.txt
8b8ff4633af0897652630903ba7155feee543a823e09ced63a14959b653a7340  py27-lowest.txt

무서운 것, 그렇지? 모든 테스트에서 두 가지만 동일한 고정 종속성을 공유합니다.

이것이 좋은 테스트 스위트를 갖춘 일반적인 파이썬 라이브러리의 현실입니다. 이제 엔터프라이즈 환경에서 테스트한 python 라이브러리와 상당히 다르다는 것을 인정할 것입니다.

진자2

jinja2 확인하면 훨씬 더 간단한 짐승으로 보입니다.

  coverage-report: commands succeeded
  py26: commands succeeded
  py27: commands succeeded
  py33: commands succeeded
  py35: commands succeeded
  py36: commands succeeded
ERROR:   docs-html: commands failed
ERROR:   py34: InterpreterNotFound: python3.4
ERROR:   pypy: InterpreterNotFound: pypy

체크섬을 보면 py27.txt와 py26.txt가 다르다는 사실에 놀랐습니다.

047a880804009107999888a3198f319e5bbba2fa461b74cfdfdc81384499864e  py26.txt
047a880804009107999888a3198f319e5bbba2fa461b74cfdfdc81384499864e  py33.txt
047a880804009107999888a3198f319e5bbba2fa461b74cfdfdc81384499864e  py35.txt
047a880804009107999888a3198f319e5bbba2fa461b74cfdfdc81384499864e  py36.txt
48bd0f6e66a6374a56b9c306e1c14217d224f9d42490328076993ebf490d61b5  coverage-report.txt
743ad9e4b59d19e97284e9a5be7839e39e5c46f0b9653c39ef8ca89c7b0bc417  py27.txt

@vlcinsky 정말 무섭

나는 이제 우리의 Python 라이브러리가 언젠가는 같은 문제를 겪지 않고 차이점을 더 쉽게 관리할 수 있기를 바랍니다.

@Moritz90 내부 라이브러리는 완전히 다른 대상에게 서비스를 제공하므로 실행 컨텍스트를 훨씬 더 좁게 유지할 수 있습니다.

일반 파이썬 라이브러리는 종종 유연하고 구성 가능합니다. 예를 들어 Flask를 사용하면 별도의 테스트 실행에서 다루는 대체 json 파서를 설치하고 사용할 수 있습니다.

Flask의 tox.ini 에서 테스트 및 독소에 대해 많은 것을 배울 수 있습니다.

가장 낮은 테스트 변형은 가장 오래된 종속성 버전에 대해 테스트합니다.

devel은 핵심 종속성의 개발 버전에 대해 테스트 중입니다.

나는 Flask가 더 높은 수준의 복잡성에 있으며 신중한 테스트 제품군을 보여줍니다.

피라미드의 tox.ini 는 비슷한 수의 환경을 보여줍니다(100% 코드 커버리지도 목표로 함).

Maya의 tox.ini 는 매우 신선하고(2일) 간단합니다. 여기에도 4가지 다른 환경이 있으며 py27은 py35 및 py36과 고정 요구 사항이 다릅니다.

@모리츠90
pipenv와 tox 사이의 접착제에 관하여

• pipenv --man 는 tox.ini 명령 내에서 pipenv 를 사용하는 방법에 대한 몇 가지 지침을 보여줍니다.
• tox-pipenv 는 추가 통합을 제공하려고 시도하지만 현재로서는 혼란스럽습니다.

tox.ini 파일은 임의의 명령을 실행할 수 있으므로 여기에는 pipenv 됩니다.

pipenv 는 이미 활성화된 virtualenv(tox 기반 테스트의 경우)에서 실행될 때 주어진 가상 환경에 설치된다는 훌륭한 기능이 있습니다. 이것은 정말 멋지다.

Pipfile.lock 생성이 필요할 수 있으므로 이를 가져오고 적절한 위치로 이동하려면 약간의 추가 노력을 기울여야 합니다(다음 테스트에 의해 덮어쓰기를 방지하기 위해 .tox/py36/Pipfile.lock 로 ag로 이동합니다. 이것은 가능하지만 약간의 단순화). Pipfile 위치에 대한 환경 변수를 사용하여 더 간단하게 만들 수 있습니다.

@vlcinsky

• setup.py - 여전히 문제를 이해하고 있는지 확실하지 않습니다. pipenv install -e . 한 번 실행하면 setup.py가 이제 잠금 파일을 통해 추적됩니다. 그런 다음 setup.py에 새 패키지를 추가할 때마다 pipenv install 를 실행합니다.
• 잠금 파일 업데이트를 잊어버린 개발자 - pipenv --deploy 는 이를 포착하기 위해 설계되었습니다. CI에서 실행하십시오!
• Pipenv 실패 - 도구에 버그가 있는 경우 동의
• 톡스
  
  
  
  • Tox가 테스트 관리에 적합하다면 훌륭합니다. 패키지 및 결정적 빌드를 관리하는 데에도 유용하다면 더욱 좋습니다.
  
  
  • 그러나 그것이 사실이라면 Pipenv가 존재할 이유가 없습니다. 그래서 나는 Tox에 어떤 종류의 제한이 있다고 가정할 수 있을 뿐입니다.
  
  
  • 위와 유사하게 오늘날 세계의 상태(좋은 상호 운용성 부족)는 철학을 거부할 이유처럼 들리지 않습니다.
  
  
• 다중 환경
  
  
  
  • 여기에는 Flask와 같은 특별한 경우가 적어도 몇 가지 있다는 것은 분명합니다.
  
  
  • 여러 개의 잠금 파일에 대한 더 나은 제안이 없습니다(비록 이와 관련하여 Pipenv에 대한 향후 기능이 있을 수 있지만?)
  
  
  • 그러나 이 경우에도 여러 잠금 파일을 관리하는 것이 실제로 문제인지 확신할 수 없습니다. 최악의 경우 로컬에서 간단한 스크립트 update-all-lockfiles.sh 를 만들고 CI에서 pipenv --deploy 를 실행하여 오류를 잡을 수 있는 것 같습니다.
  
  

@Moritz90 - 동의합니다. 대부분의 경우 "2단계" 접근 방식이 과도할 수 있습니다. 특히, 잠금 파일에 고의적/의도적 "수동" 업데이트를 수행하는 경우 완전히 불필요합니다.

더 일반적으로, 이 "제안"이 실제로 어려운 문제에 초점을 맞추도록 하는 것이 좋을 것입니다(제 생각에는 (A) 여러 환경에 서비스를 제공하고 (B) 업스트림 종속성의 변경 사항을 포착하려는 것입니다). 일시적인 것(Pipenv의 버그)이나 도구 사용 방법에 대한 잠재적인 오해를 기반으로 해서는 안 됩니다.

그러나 이러한 "어려운" 문제의 경우에도 프레이밍은 "일부 복잡한 가장자리의 경우 기본 Pipenv 워크플로가 불충분하다는 것을 알 수 있으므로 여기에 몇 가지 생각할 사항이 있습니다."와 같아야 합니다. IMO, 기본 접근 방식으로 구성되어서는 안 됩니다(대부분의 사람들이 이러한 우려를 갖지 않기 때문입니다).

Pipenv / Pipfile가의 처리를 허용 할 경우 제공 documentaion 예제 @vlcinsky는 혼란 간단하고 덜 될 것입니다 lib-dependencies , app-dependencies 및 dev-dependencies . 문서는 다음과 같이 보일 수 있습니다.

패키지가 공유 라이브러리인 경우 lib-dependencies 옵션을 사용하십시오. 예 Pipfile :

[lib-dependencies]
some-lib=="*"
another-lib=="*"
yet-another-one==">=1.0"

[dev-dependencies]
some-dev-tool=="1.1"

공유 라이브러리의 경우 소비자 시스템에서 버전 충돌을 방지하기 위해 가능한 한 [lib-dependencies] 미만의 버전 범위를 유지하는 것이 중요합니다.

패키지가 정확한 종속성 버전이 필요한 응용 프로그램(대상 시스템에서 pipenv에 의해 설치됨)인 경우 [app-dependencies] 옵션을 사용해야 합니다. 예 Pipfile :

[app-dependencies]
some-lib=="1.0.12"
another-lib=="1.*"
yet-another-one=="2.0"

[dev-dependencies]
some-dev-tool=="1.1"

/End 문서 예제

또 다른 접근 방식은 Pipfile.lib 및 Pipfile.app 있습니다.

나는 이와 같은 것이 격차를 채우기 위해 안티 패턴 섹션과 타사 도구의 덩어리에 대한 필요성을 생략할 것이라고 생각합니다.

pipenv 패키징 도구를 호출하는 것은 파이썬 라이브러리를 생성하거나 생성에 깊이 관여할 것으로 예상하는 경우 오해의 소지가 있습니다.

나는 이것이 많은 혼란을 초래하는 실제 문제라고 생각합니다. 특히 다른 프로그래밍 언어(예: JS, Rust, Elm)로 패키지 관리자를 사용하는 사람들 사이에서는 더욱 그렇습니다. 내가 Pipenv와 setup.py를 잘못된 방식으로 사용하고 있다는 것을 깨달을 때까지 몇 달이 걸렸고 가끔 Github 문제를 읽었습니다.

@feluxe

귀하의 [lib-dependencies] 또는 Pipfile.lib 는 오늘날 Pipfile (추상 종속성 - 가능한 한 광범위함).

귀하의 [app-dependencies] 또는 Pipfile.app 는 Pipfile.lock (특정 종속성으로).

pipenv 및 해당 파일은 라이브러리 개발 또는 응용 프로그램 배포 준비라는 두 가지 다른 상황에서 사용할 수 있지만 두 가지 모두를 동시에 사용할 수는 없습니다. 이러한 이유로 Pipenv 추가 섹션을 추가해야 하는 강력한 이유는 보이지 않습니다. Pipfile 이 어떤 유형의 용도로 사용될 것인지 아는 것은 개발자의 책임입니다.

나는 이것이 많은 혼란을 초래하는 실제 문제라고 생각합니다. 특히 다른 프로그래밍 언어(예: JS, Rust, Elm)로 패키지 관리자를 사용하는 사람들 사이에서는 더욱 그렇습니다. 내가 Pipenv와 setup.py를 잘못된 방식으로 사용하고 있다는 것을 깨달을 때까지 몇 달이 걸렸고 가끔 Github 문제를 읽었습니다.

동의. 3섹션 솔루션은 제가 생각해 본 적이 없는 매우 흥미로운 솔루션이기도 하며 정확하고 (놀랍게도!) 간단해 보입니다.

Python 배경에서 온 저는 항상 Node의 package.json이 잘못하고 있다고 느꼈습니다(Rust는 컴파일러와 링커가 있고 나중 단계에서 해결할 수 있기 때문에 더 좋습니다). 앱과 라이브러리 종속성을 같은 방식으로 처리하는 것은 최소한 추상적인 의미에서 Python과 같은 스크립팅 언어에서는 작동하지 않습니다. 일반적인.

개념적으로는 3섹션 솔루션이 마음에 들지만 여전히 기존 생태계와 호환되지 않는 변경 사항입니다. 이 공간을 채우는 setup.py, setup.cfg 및 (잠재적으로) pyproject.toml이 이미 있습니다. Pipenv(정확히 말하면 Pipfile)가 공간으로 이동하려면 pip(라이브러리 지원은 이상적으로는 직접 지원해야 함) 및 flit 과 같은 관련 프로젝트와 통합해야 합니다.

lib/app 종속성 처리에 관한 다른 문제에서 언급했듯이 이 논의는 pypa-dev(메일링 리스트) 및/또는 PEP 프로세스로 에스컬레이션되어야 합니다. (Pipfile)은 모든 방향으로 이동할 수 있습니다.

@vlcinsky

귀하의 [lib-dependencies] 또는 Pipfile.lib는 오늘날 Pipfile에 있는 것입니다(추상 종속성 - 가능한 한 광범위함).

이것이 명확하지 않은 경우 죄송합니다. 내 lib-dependencies 는 사람들이 현재 setup.py / install_requires 넣는 것입니다. 아마도 pypi-dependencies 가 내가 의미하는 바에 더 나은 이름이 될 것입니다.

@uranusjr

이 공간을 채우는 setup.py, setup.cfg 및 (잠재적으로) pyproject.toml이 이미 있습니다.

Pipenv(명령줄 도구)는 setup.py 인터페이스할 수 있습니다. setup.py 의 종속성 섹션만 Pipfile로 이동해야 합니다. 적어도 내 상상에서는 :)

lib/app 종속성 처리에 관한 다른 문제에서 언급했듯이 이 논의는 pypa-dev(메일링 리스트) 및/또는 PEP 프로세스로 에스컬레이션되어야 합니다. (Pipfile)은 모든 방향으로 이동할 수 있습니다.

알겠습니다. 귀찮게 해서 죄송합니다 ;) 시간이 나면 메일링 리스트에 쓸 내용을 작성하겠습니다.

그러나 이 제안의 범위 내에서 전체 Python 패키징 커뮤니티를 위한 새로운 워크플로를 작업하는 토끼 구멍으로 들어가는 대신 현재 가능한 모범 사례에 초점을 맞추는 것이 좋습니다. 현재 제약 조건 내에서 모범 사례를 제안한 다음 개선 논의를 시작하는 것이 더 생산적입니다.

@uranusjr - "컴파일된" 배경에서 왔는데 왜 이런 일이 일어나는지 궁금합니다.

앱과 라이브러리 종속성을 같은 방식으로 처리하면 Python과 같은 스크립팅 언어에서는 작동하지 않습니다.

@tsiq-oliverc 앱의 모범 사례에서는 종속성을 고정해야 하므로 동일한 요구 사항 파일 소스를 사용하는 경우 라이브러리도 종속성을 고정하기 시작합니다. 이것은 의존성 해결에 문제를 일으킬 것입니다.

내 앱에 두 개의 종속성 A와 B가 있고 둘 다 C에 종속되어 있지만 A는 v1을, B는 v2를 핀으로 고정한다고 가정해 보겠습니다. 컴파일된 언어를 사용하면 툴체인이 컴파일 시간에 이를 감지하고 다양한 방식으로 해결할 수 있습니다. 예를 들어, Rust는 링크 시간 동안 이 작업을 수행합니다. 최종 실행 파일에는 두 개의 C 복사본(v1 및 v2)이 포함되며 A와 B는 각각에 연결됩니다. C++ 영역에서는 동적 라이브러리로 해결됩니다. 기호 조회는 나중에(런타임에) 수행되지만 아이디어는 동일합니다. 컴파일러는 사용자가 사용하는 인터페이스에서 필요한 것을 알고 그에 따라 작동할 수 있습니다.

스크립팅 언어는 실제로 호출에 도달할 때까지 실제로 무엇을 하고 싶은지 모르기 때문에 이를 수행할 수 없습니다. 노드는 항상 종속성이 호환되지 않는다고 가정하여 이 문제를 해결하지만(두 복사본이 동일하더라도 A와 B는 항상 고유한 C를 얻음) 이는 새로운 유형의 문제를 야기하고 모든 사람이 (희망?) 끔찍하다는 데 동의합니다. Python은 아마도 거기에 가고 싶지 않을 것입니다(어쨌든, 그렇게 하면 기존의 모든 Python 설치가 중단될 수 있기 때문에 갈 수 없습니다).

이 문제를 해결하는 또 다른 방법은 종속성 버전을 "고정 해제"하는 패키징 도구에서 영리한 작업을 수행하는 것입니다. (Ruby의) Bundler는 사람들에게 잠금 파일을 gem에 포함하지 않도록 권장하여 이를 수행하므로 Bundler는 Gemfile.lock의 고정된 버전 대신 Gemfile의 고정되지 않은 버전을 사용할 수 있습니다. 그러나 사람들은 조언을 무시하고 원하는 대로 하는 경향이 있으므로 여전히 도처에서 고정 버전을 얻습니다.

나는 그것이 단순히 작동하지 않을 것이라고 말하기에는 아마도 너무 강했을 것입니다. 그러나 적어도 이전의 모든 시도는 실패했으며 시도한 많은 사람들은 나보다 훨씬 똑똑한 매우 똑똑한 사람들입니다. 저는 개인적으로 이것이 가능하다고 생각하지 않으며 실제로 그것을 수행하는 매우 훌륭한 제안을 볼 때까지 계속 이런 식으로 생각할 것입니다.

@tsiq-oliverc Pieter Hintjens는 "댓글은 풀 리퀘스트 형식으로 환영합니다"라는 개념을 어딘가에 썼습니다.

철학적 조언에서 실제로 유형적이고 실용적인 것으로 초점을 이동하기 때문에 나는 그것을 좋아합니다. 또한 댓글 작성자는 아이디어가 불완전하거나 실제 사용에서 어떻게 든 깨진 방법에 대해 종종 배우기 때문에 댓글 수를 제한합니다.

pipenv 가 제대로 사용(또는 최소한 사용)된 python 라이브러리의 예를 요청했는데 아무 것도 제공하지 않았습니다.

tox 품질에 대해 언급했지만 익숙하지 않다는 것을 인정하고 여전히 파이썬 패키지 개발 세계의 모범 사례에 대해 반복합니다.

Flask 는 특별한 경우일 수 있습니다. 그래서 나는 Github에서 "library"라는 단어를 사용하여 파이썬 프로젝트를 검색했는데, 포크 수에 따라 정렬되었고(아마도 얼마나 많은 사람들이 개발을 하고 있는지 반영할 수 있음), 모든 "어떤 것의 선별된 목록"을 무시하고 하나에 대한 환경의 수를 계산했습니다. OS(일반적으로 Linux):

• 팬더 : tox.ini: 6 환경
• 토네이도 : tox.ini: 30!! 환경
• Theano : .trafis.yml: 12개 환경
• scipy : tox.ini: 4 환경
• zipline : .travis.yml: 2개 환경
• tflearn : .travis.yml: 2 환경
• yowsup : tox.ini: 7 환경
• 비트 : tox.ini: 4개
• 작업 : tox.ini: 8 환경
• paramiko : tox.ini: 6 환경
• docker-py : tox.ini: 6개 환경
• 베개 : tox.ini: 4개

테스트를 실행할 실제 환경의 수는 대부분 2배(+Windows) 또는 3배(+OSX)입니다.

tox 는 3개 중 2개의 프로젝트에서 사용됩니다(다른 수준의 테스트를 수행하기 때문에 Travis 또는 Appveyor와 비교하지 않습니다).

테스트할 환경의 수는 다소 높지만 Flask는 확실히 가장 거친 환경이 아닙니다.

고정 종속성을 정의할 환경의 수는 실제로 수동으로 관리할 수 없습니다.

단순히 Pipfile.lock 를 저장소에 놓는 것은 다소 쉽지만 마법의 개선은 없습니다(그렇다면 상황이 개선될 때 실제 시나리오를 보여주세요).

아마도 당신은 "컴파일된" 세계의 황금률을 알고 있고 Python에서도 결정성(또는 반복성)이 필수 요소라고 느낄 것입니다. 보시다시피, 실제로 많은 Python 프로젝트가 그것 없이는 잘 살기 때문에 황금률이 ​​여기에서 그렇게 엄격하게 적용되지 않을 수 있습니다.

상황을 개선할 python 라이브러리에 대해 pipenv 사용을 찾으면 기쁠 것입니다. 그리고 전반적인 품질에 해를 끼치는 사용을 방지하고 싶습니다.

그 목표에 도달하기 위해 내 접근 방식은 질문을 반복하는 것입니다.

• 도구를 사용할까요?
• 어떻게?
• 왜, 나는 어떤 가치를 얻었습니까?
• 그것은 몇 가지 문제를 도입 했습니까? (추가 작업, 오류 숨김...)

@feluxe

이것이 명확하지 않은 경우 죄송합니다. 내 라이브러리 종속성은 사람들이 현재 setup.py / install_requires에 넣는 것을 의미합니다. 아마도 pypi-dependencies가 내가 의미하는 바에 더 나은 이름이 될 것입니다.

이 호에서 pbr 토론을 참조하십시오. Pipfile에서 라이브러리 종속성을 지원하려는 노력입니다.

하나의 Pipfile 는 두 가지 용도(lib와 app)로 사용되어서는 안 된다고 생각합니다. 이것들은 별도로 해야 합니다. 정말 필요하다고 느끼신다면 이를 활용한 프로젝트의 목적을 말씀해 주시겠습니까? 나는 일반적으로 라이브러리 개발과 배포 프로젝트가 시간에 따라 상당히 다르기 때문에 분리된 상태로 유지하려고 합니다.

@vlcinsky 나는 당신이 이것을 어디로 가져가고 싶은지 잘 모르겠습니다(어떤 종류의 PR을 요구하는지 모르겠습니다!), 그래서 나는 지금 이 대화에서

내 입장의 TL;DR을 다시 말하려면:

1. 결정적 빌드는 매우 바람직하고 소프트웨어 산업의 다른 곳에서 일반적이며 Pipenv로 쉽게 달성할 수 있습니다.
2. 분명히 일부 극단적인 경우가 있으며 누군가가 (해결 방법 또는 더 나은 도구를 통해) 최첨단 기술을 추진해야 합니다.
3. Pipenv 문서가 (2) 사례의 작은 하위 집합에 영향을 미치기 때문에 단순히 (1)에 대해 추천하는 것은 무책임합니다.

@uranusjr 알겠습니다. 여기에 특정 언어가 있다고 생각하지 않지만, 단순히 다른 커뮤니티가 일반적인 솔루션 없이 문제를 처리하기 위해 다른 발견적 방법을 사용했다는 것입니다. 버전 충돌이 있는 경우 문제가 있는 것입니다.

Maven/Java(예:)는 빌드 시 이에 대해 생각하도록 합니다. NPM 방식은 일치하지 않는 버전이 인터페이스를 교차하는 경우 런타임 문제가 있음을 의미합니다. 런타임 확인(예: Python, 동적 라이브러리)은 종속 항목이 충돌할 수 있음을 의미합니다. 종속성 버전이 예상한 것과 다른 경우.

@vlcinsky

이 문제의 pbr 토론을 참조하십시오. Pipfile에서 라이브러리 종속성을 지원하려는 노력입니다.

pbr은 훌륭해 보이지만 다음과 같이 해결하려고 했던 범주에 속합니다.

나는 이와 같은 것이 격차를 채우기 위해 안티 패턴 섹션과 타사 도구의 덩어리에 대한 필요성을 생략할 것이라고 생각합니다.

그런 도구는 애초에 필요하지 않아야 한다고 생각합니다.

정말 필요하다고 느끼신다면 이를 활용한 프로젝트의 목적을 말씀해 주시겠습니까? 나는 일반적으로 라이브러리 개발과 배포 프로젝트가 시간에 따라 상당히 다르기 때문에 분리된 상태로 유지하려고 합니다.

pypi 패키지의 경우 개발 종속성을 처리하기 위해 Pipenv를 사용하고, dev 종속성을 설명하기 위해 Pipfile 를, install_requires 및 setuptools lib 종속성을 설명하기 위해 setup.py 를 사용했습니다 setuptools in setup.py pipenv run python setup.py bdist_wheel upload 실행 중인 패키지 게시 이것이 내가 복잡하다고 생각하는 것입니다.

다른 현대 언어에서는 하나의 명령줄 도구(패키지 관리자)와 하나의 종속성 파일 형식을 배워야 합니다. 문서는 한 곳에서 쉽게 따라할 수 있으며 초보자도 몇 시간 안에 이 모든 것을 정리할 수 있습니다. npm init , npm install foo --dev , npm publish 입니다. Pipenv/Pipfile은 이미 대부분의 작업을 수행할 수 있습니다. 모든 작업을 수행할 수 있다면 이와 같은 문제는 존재하지 않을 것입니다.

나는 이 토론에 대한 일종의 "커뮤니티" 섹션/위키에 대한 나의 요청을 다시 설명합니다. 합법적인 "패턴"이 여러 개 있으며 우리 중 일부는 "python 라이브러리를 수행하는 방법"을 공유하고 싶어할 수 있으며, 나와 같은 일부는 pbr을 사용하고 다른 일부는 매우 좋은 패턴을 가질 수 있습니다. 그러나 pipenv 문서 내부의 페이지는 좋은 생각인지 확실하지 않습니다.

추신: 새 pypi로의 마이그레이션을 준비하려면 python setup.py 업로드가 아닌 꼬기를 사용해야 합니다. "업로드"를 사용하는 것은 안티패턴으로 간주되어야 합니다.

pipenv가 "게시" 명령을 키울 수 있습니까?

@feluxe 시를 보고 싶을 수도 있습니다. 나는 그것을 우연히 발견했고 그것이 당신이 찾고있는 것 같습니다.

그것은 pipenv 가 하는 일과 그 이상을 수행하며 특히 종속성 관리와 관련하여 더 잘 수행하는 것 같습니다(적어도 그들이 가장하는 것입니다). 종속성 관리, 패키징 및 모든 단일 도구 poetry 게시를 수행합니다.

pipenv 및 poetry 가 마침내 Python에게 진정한 패키지 관리자를 제공하기 위해 노력을 모을 수 있는지 궁금합니다.

이 논의가 너무 지나치기 전에 다시 한 번 말씀드리고 싶습니다. Pipenv는 단순히 publish 명령을 확장하거나 패키징 의무를 인계하려는 모든 작업을 수행할 수 없습니다. 모든 사람이 이런 식으로 하는 것은 아니기 때문에 생태계가 더 파편화될 뿐이고 앱과 라이브러리 종속성이 이론적으로 다르기 때문에 워크플로에서 구분이 이루어지면 다시 병합하라고 말할 수 없습니다.

거의 모든 사람이 이 병합에 참여하고 있는 것처럼 보일 수 있지만 사실은 일이 잘 되고 다른 일을 하고 있기 때문에 이 토론에 참여하지 않는 사람들이 훨씬 더 많습니다. 반복해서 말했습니다. 도구 체인 및 파일 형식의 디자인 개선에 대한 논의는 Python 패키징 계층 구조의 상위 위치에서 이루어져야 하므로 Pipenv가 의존하는 보다 근본적인 것을 설계하는 사람들에게 더 많이 노출됩니다. 그곳에서 토론을 하시기 바랍니다. Pipenv가 변경할 위치에 있지 않기 때문에 여기에서 제안하는 것은 아무 소용이 없습니다.

반복해서 말했습니다. 도구 체인 및 파일 형식의 디자인 개선에 대한 논의는 Python 패키징 계층 구조의 상위 위치에서 이루어져야 하므로 Pipenv가 의존하는 보다 근본적인 것을 설계하는 사람들에게 더 많이 노출됩니다.

패키징 및 게시가 시작되면서 이 버그에 대한 논의가 통제 불능이라는 데 동의합니다(이 버그는 종속성 관리에 관한 것뿐입니다!). 하지만 이 토론을 할 수 있는 올바른 장소를 알려 주시겠습니까? 사람들은 pipenv가 올바른 방향으로 매우 필요한 단계로 간주되기 때문에 여기에 있는 것입니다. pipenv 유지 관리자에게 추가 책임을 부과하기를 원하기 때문이 아닙니다.

편집 : 죄송합니다. 새 댓글을 처음 읽을 때 정확히 그렇게 한 게시물을 놓쳤을 것입니다.

그러나 이 제안의 범위 내에서 전체 Python 패키징 커뮤니티를 위한 새로운 워크플로를 작업하는 토끼 구멍으로 들어가는 대신 현재 가능한 모범 사례에 초점을 맞추는 것이 좋습니다. 현재 제약 조건 내에서 모범 사례를 제안하고 개선을 위한 논의를 시작하는 것이 더 생산적입니다.

나는 이것에 매우 동의합니다. 우리는 먼저 도서관 관리자들에게 최적의 워크 플로우 지금 우리는 큰 계획을 마련하기 전에 무엇인지 파악해야한다. 이 스레드의 시작 부분에서 했던 것처럼 다시 그것에 초점을 맞춰 보겠습니다. 아직 결론에 이르지 못했다고 생각합니다.

주제로 돌아가기: 라이브러리에 대해 다른 파일에서 종속성을 정의해야 하는 이유에 대한 @uranusjr 의 게시물 인용:

이 문제를 해결하는 또 다른 방법은 종속성 버전을 "고정 해제"하는 패키징 도구에서 영리한 작업을 수행하는 것입니다. (Ruby의) Bundler는 사람들에게 잠금 파일을 gem에 포함하지 않도록 권장하여 이를 수행하므로 Bundler는 Gemfile.lock의 고정된 버전 대신 Gemfile의 고정되지 않은 버전을 사용할 수 있습니다. 그러나 사람들은 조언을 무시하고 원하는 대로 하는 경향이 있으므로 여전히 도처에서 고정 버전을 얻습니다.

나는 그것이 단순히 작동하지 않을 것이라고 말하기에는 너무 강했을 것입니다. 그러나 적어도 이전의 모든 시도는 실패했습니다.

현재로서는 라이브러리에 대한 공식 권장 사항이 CI 빌드에 pipenv 를 사용할 수 없지만 Pipfile.lock 를 소스 제어에서 제외하는 이유를 여전히 모르겠습니다. 몇몇 사람들이 지적했듯이 pipenv 는 현재 패키징 프로세스와 아무 관련이 없으므로 위에서 설명한 문제가 발생하지 않아야 합니다.

또한 이것이 애플리케이션이 추상 종속성을 정의하는 데 사용하는 동일한 파일에서 추상 종속성을 정의하는 것에 반대하는 주장인 이유도 알 수 없습니다. pipenv 가 Pipfile 와 setup.py 를 통합하기 위한 정교한 솔루션을 구현하고 싶지 않다면 괜찮습니다. 하지만 그것이 일반적으로 왜 나쁜 생각인지 모르겠습니다.

@vlcinsky

하나의 Pipfile을 두 가지 용도(lib와 app)로 사용해서는 안 된다고 생각합니다. 이 작업은 별도로 수행해야 합니다.

내 위의 게시물을 참조하십시오. 왜 그렇게 생각하는지 자세히 설명해 주시겠습니까? 나는 원칙적으로 어떤 단점도 볼 수 없습니다. 지금 당장은 Pipfile 를 포함하는 것이 좋지 않을 수 있습니다. 그러면 두 개의 다른 파일에서 동일한 방식으로 종속성을 정의해야 하기 때문입니다. 일반적으로 종속성 선언에 Pipfile 를 사용하는 것은 좋지 않습니다.

나와 같은 상황에 있지 않는 한 Pipfile.lock 가 라이브러리의 소스 제어에 있어서는 안 된다는 데 이미 동의했습니다.

편집 : 또한 pipenv 자체가 실제로 차이점에 대해 알아야 하는 것으로 판명되면 app-dependencies 및 lib-dependencies 도입을 시작하기 전에 화물의 crate-type 필드와 같은 것을 도입할 수 있습니다. lib-dependencies - 너무 복잡하게 들립니다.

@Moritz90 Python의 메일링 리스트 중 일부는 이 토론을 개최하기에 좋은 장소입니다.

pypa-dev 는 Python 패키징 및 이를 둘러싼 생태계를 중심으로 논의하는 데 가장 확실합니다. 비슷한 토론을 게시하려면 여기에서 시작할 것입니다.

python-ideas 는 아이디어를 논의할 수 있는 장소이며 전체 Python 커뮤니티에 대한 가시성이 매우 높습니다. 이것을 PEP 수준으로 밀어붙이고 싶다면 좋은 출발점이 될 것입니다.

@tsiq-oliverc

PR의 의미는 다음과 같습니다. 귀하의 개념이 실행 가능함을 증명하는 예를 보여주십시오.

따라서 기존 라이브러리를 선택하고 포크하고 (1)을 적용합니다. pipenv 로 쉽게 될 것이라고 말하고 나에게 보여줍니다. 꽤 노력했고 어려움을 겪었습니다.

귀하의 (2)가 "다른 사람이 작업을 수행해야 함"을 의미하는 경우 귀하의 PR은 존재하지 않습니다.

(3)에서 실수를 제공하지 않고 "작은 부분 집합 사례"에 대해 이야기합니다. virtualenv의 수와 관련하여 내가 설명한 모든 상위 라이브러리가 "작은 하위 집합"으로 간주됩니까?

이 토론을 마치기 위해 토론 중에 발견한 내용에 대한 간략한 요약을 만들었습니다.

초점: Python 라이브러리 및 애플리케이션을 위한 pipenv (안티) 패턴

나는 초점을 약간 바꿨다. 그것은 (일반) 파이썬 라이브러리뿐만 아니라 그것을 포함하는 것이 다소 저렴하고 차이점을 잘 보여주기 때문에 응용 프로그램에 대해서도 이야기합니다.

pipenv , tox 등과 같은 기존 도구의 변경을 제안하는 것은 의도적으로 제외했습니다.

pipenv 이란 무엇이며 무엇이 아닌지

• Pipfile.lock 를 통해 구체적인 종속성을 정의하고 적용할 수 있는 배포 도구입니다.
• virtualenv 관리 도구입니다.
• 파이썬 패키지를 생성한다는 의미에서 패키징 도구가 아닙니다.

라이브러리 및 애플리케이션

(python 소프트웨어) 제품은 다른 제품(따라서 라이브러리)에서 사용할 준비가 되었거나 실행할 준비가 된 최종 응용 프로그램입니다.

개인적으로 "엔터프라이즈 라이브러리"도 라이브러리 범주에 속한다고 생각합니다(같은 규칙이 적용되고 실행 컨텍스트의 수만 더 적음).

소프트웨어 제품의 종류

• 라이브러리: 다른 제품(라이브러리 또는 애플리케이션)에서 사용
• 응용 프로그램: 배포 및 실행

설치 방법:

• library: pipenv install <package> 따라서 "패키지 실행(다른 라이브러리의 버전 확인)"
• application: pipenv sync 따라서 "구체적인 종속성 적용"

추상적이고 구체적인 종속성

소프트웨어 제품 종속성

• 추상 종속성: 사용된 라이브러리의 이름을 지정해야 하며 버전 또는 사용을 제한할 수 있지만 충분히 유연해야 합니다(버전을 고정하지 않아야 함).

• 구체적인 종속성: 이상적으로 사용된 라이브러리의 해시와 함께 버전을 고정해야 합니다.

  pipenv 유물:

• Pipfile : 추상 종속성

• Pipfile.lock : 구체적인(잠긴) 종속성"

실행 컨텍스트

다른 실행 컨텍스트의 일반적인 수

• 도서관:
  
  
  
  • 하나의 OS에서 python virtualenvs: 3 ~ 9(30을 사용하는 토네이도)
  
  
  • OS 수: 1 ~ 3(Linux, OSX, Windows)
  
  
  • 총 수: 3 ~ 18
  
  
• 애플리케이션:
  
  
  
  • 하나의 OS에서 python virtualenvs: 1
  
  
  • 운영 체제 수: 1
  
  
  • 총 수: 1(또는 매우 적은 수)
  
  

CI 목표, 우선순위 및 결정론

CI 목표

• 도서관:
  
  
  
  • 코드 포함 추상 종속성은 실행 컨텍스트의 모든 예상 변형 내에서 설치 및 예상 기능을 허용합니다.
  
  
  • (개인/공용) pypi가 종속성 라이브러리 업데이트를 가져올 때 테스트된 라이브러리 설치 기능에 영향을 미치는 경우 실패합니다.
  
  
• 애플리케이션:
  
  
  
  • 설치 시(구체적/고정된 종속성 사용) 모든 예상 기능이 사전 정의된 하나의 실행 컨텍스트 내에서 제공됩니다.
  
  

기능에 관한 특정 CI 목표:

• 도서관:
  
  
  
  • 라이브러리에 의해 선언된 추상 종속성은 완전하고 필요한 모든 제한을 포함합니다(필요한 경우에만): 라이브러리가 자체적으로 올바르게 설치됩니다.
  
  
  • 모든 예상 사용 사례가 제대로 작동합니다.
  
  
• 애플리케이션:
  
  
  
  • 구체적인 종속성이 완전하고 모든 것이 고정되어 있습니다. 해시: 응용 프로그램이 제대로 설치됩니다.
  
  
  • 모든 예상 사용 사례가 제대로 작동합니다.
  
  

다양한 CI 테스트 모드

• 모드: "달려라 포레스트 달려라"
  
  
  
  • 오늘날 대부분의 파이썬 라이브러리는 이런 방식으로 테스트됩니다.
  
  
  • tox 또는 유사한 테스트 SW 사용
  
  
  • pipenv 및 구체적인 종속성을 사용하지 않음(라이브러리에 적합할 수 있음)
  
  
• 모드: "생성 및 봉인"
  
  
  
  • 저장소에 Pipfile 없음
  
  
  • Pipfile.lock 만든 pipenv install -e .
  
  
  • Pipfile.lock 환경을 문서화(봉인)하고 나중에 문제 분석을 위해 virtualenv를 복제할 수 있습니다.
  
  

• 모드: "아이스 에이지"

  • 2단계 테스트
    
    
    
    • 추상 종속성( setup.py install_requires 내에 정의됨)이 변경되거나 pypi의 종속 패키지가 업데이트되면 pipenv install -e . Pipfile.lock 를 재생성합니다.
    
    
  • 기능 테스트 실행: 라이브러리 코드가 변경될 때 실행합니다. pipenv sync Pipfile.lock 의해 생성된 virtualenv 내에서 실행됩니다.
    

    Pipfile.lock 는 어떻게 그리고 누가 만들 수 있습니까?

• 개발자가 수동으로(응용 프로그램에서 작동할 수 있음)

• CI 빌드에 의해 자동으로 (모든 테스트를 통과하고 검증된 인공물 선언)

결정론 대 유연성의 우선 순위

• 라이브러리: 유연성(가능한 경우 실행)

• 응용 프로그램: 결정성(선택한 실행 컨텍스트 내에서 정확히 동일한 방식으로 실행)

  설치된 제품의 결정성에 영향을 줄 수 있는 사항:

• 공개 pypi(낮은 결정성, 패키지는 언제든지 업데이트됨)

• private pypi(높은 결정성, 패키지 업데이트가 제어될 수 있음)
• 라이브러리 내의 추상 요구 사항(결정론에 사용되지 않음)
• 구체적인 요구 사항( Pipfile.lock ): 총체적 결정론

여러 가지 잡다한

Pipfile.lock 일부 사용 사례:

• (반패턴) 라이브러리 추상 종속성을 정의합니다(추상이어야 하기 때문에)
• (반패턴) 테스트된 라이브러리에 대한 virtualenv 설정(깨진 라이브러리 추상 종속성을 숨길 수 있음)
• 테스트가 실행된 정확한 virtualenv("봉인")를 문서화합니다(따라서 개발자가 나중에 깨진 테스트 및 실험을 위해 다시 만들 수 있음).
• 테스트된 애플리케이션에 대한 virtualenv 설정

• 프로덕션에 애플리케이션 배포

  기타 힌트

• pbr 라이브러리는 requirements.txt 를 통해 추상 라이브러리 종속성을 정의할 수 있습니다. Pipfile 업데이트가 진행 중입니다.

• poetry 패키지는 pyenv 와 유사한 것을 시도합니다.

  일반적인 문제

• "잠금 파일을 repo에 드롭"하면 결정적 빌드가 표시됩니다.

  • 응용 프로그램에서 작동합니다.
  • 실제로 수많은 실행 컨텍스트가 있고 각각 다른 Pipfile.lock 가 발생할 가능성이 높기 때문에 라이브러리에서는 작동하지 않습니다. 진지하게: flask 는 11개의 다른 가상 환경(하나의 OS에서) 10개의 다른 잠긴 종속성을 보여줍니다. 누가 만들고 커밋할 것인가?
  • "생성 및 봉인" CI 모드를 사용하면 여전히 Pipfile.lock (CI 스크립트에 의해 생성됨)를 얻을 수 있으므로 다른 곳에서 virtualenv를 다시 생성할 수 있습니다.
• Pipfile.lock 라이브러리 저장소
  
  
  
  • virtualenv를 만드는 데 사용되는 경우 setup.py 내에서 라이브러리 종속성의 깨진 정의를 숨길 수 있습니다.
  
  
• Pipfile 라이브러리 저장소
  
  
  
  • setup.py 내에서 정의되는 추상 종속성을 반복하는 경우 깨진 setup.py 종속성 선언을 숨길 수 있습니다.
  
  
  • 추천 : 생성 Pipfile 로 pipenv install -e . 또는 pipenv install -e .[tests] 당신은 또한 테스트 종속성 그들은 "테스트"를에 엑스트라로 선언 필요하다면 setup.py
  
  
• CI 스크립트에 pipenv install <something> 추가
  
  
  
  • 자체적으로는 결정론을 많이 향상시키지 않습니다.
  
  
  • "생성 및 봉인" CI 모드를 참조하십시오(그런 다음 virtualenv에 대한 모든 설치는 pipenv 거쳐야 함).
  
  

결론

Python 라이브러리(특히 일반 라이브러리)는 예기치 않게 많은 수의 실행 컨텍스트를 나타냅니다. 그 이유는 라이브러리의 목표는 다양한 조건에서 입증된 유연성이기 때문입니다. 결정적 빌드보다 유연성이 더 중요해 보입니다. "컴파일" 세계에서 온 사람들에게 이것은 매우 나쁜 반패턴처럼 느껴질 수 있습니다. 사실은 대부분의(아마도 모든) Python 라이브러리가 결정론적 빌드를 제공하지 않으며(일부 알고 있는 경우 알려주세요) Python은 여전히 ​​잘 작동하고 있습니다. Python 응용 프로그램이 살아 있는 이유는 다음과 같습니다. 스크립팅 언어로서의 Python이 컴파일된 세계와 다릅니다. 다른 이유는 결정론이 나중에 한 단계 나중에 해결될 수 있고 애플리케이션(라이브러리 집합에서 빌드)이 결정론에 대한 (자연스럽고 정당한) 요구 사항을 해결해야 하기 때문일 수 있습니다.

응용 프로그램의 경우 상황이 정반대이며 여기서 pipenv 와 같은 도구를 사용하면 결정론에 쉽게 도달할 수 있습니다.

다음에 무엇을할지?

• 다음 주나 2주 동안 이 문제를 처리할 시간이 없을 것입니다.
• 어딘가에 일련의 블로그 항목을 만드는 것을 상상할 수 있습니다(어디서인지 확실하지 않음). 장소를 알고 있다면(이상적으로는 약간의 토론이 허용됨), 내용을 참조하고 토론하고 마지막으로 (만약 살아남는 경우) 어딘가에 돌로 놓아두는 것이 자연스러운 장소가 될 것입니다 :-).
• 나는 @uranusjr 이 이 문제의

매우 고무적인 토론을 해주신 모든 분들께 감사드립니다. "나는 이 주제에서 완전히 빠졌습니다"라는 메시지가 세 번 리팩토링된 것처럼 느껴집니다. 이는 자연스럽게 우리가 좋아졌다는 것을 의미합니다.

@vlcinsky poetry 는 pyenv 와 아무 관련이 없습니다. pipenv (그러나 라이브러리 및 응용 프로그램, IMO 관리와 관련하여 훨씬 더 나은 구현이 있음)와 비슷하지만 패키징 및 게시 부분이 있습니다.

당신은이 pyproject.toml 프로젝트 및 종속성 (추상 의존성)과 정의 파일을 pyproject.lock 고정 된 종속성을 설명하고 파이썬 버전 및 플랫폼에 고정되어 어느 pyproject.toml pipenv 이 직면한 문제를 피하기 위해 하나의 결정적 잠금 파일만 갖도록 파일을 지정했습니다. poetry 는 설치할 때만 환경에 대해 확인하여 설치할 패키지를 확인합니다.

그리고 라이브러리를 패키징할 때 고정된 종속성이 아닌 추상 종속성을 사용하므로 패키지를 배포할 때 유연성을 유지할 수 있습니다(예: PyPI를 통해).

이것의 장점은 라이브러리에 대한 추상 종속성과 응용 프로그램에 대한 잠금 파일을 사용한다는 것입니다. 이것은 두 세계의 최고입니다.

고정된 종속성을 사용하지 않는 @zface 시는 말 그대로 전체 목적을

본질적으로 우리는 사람들이 극단적인 경우를 겪지 않기 때문에 거창한 주장을 하는 소규모 프로젝트가 많은 노력을 들일 필요가 없는 복원력에 많은 시간과 노력을 투자합니다. 다른 도구가 모든 세계의 최고를 제공한다고 진정으로 믿는다면 이를 사용하는 것이 좋습니다. pipenv 자체는 가까운 시일 내에 패키징을 처리하지 않을 것입니다.

@techalchemy 저는 아무 것도 판매하지 않습니다. 실제로 pipenv 에서 사용할 수 있는 아이디어를 안내하는 것입니다.

그리고 poetry 는 pipenv 가 Pipfile.lock 에서 하는 것처럼 pipenv pyproject.lock 에서 종속성을 고정합니다. 따라서 pipenv 제공하는 것과 같은 재생산이 가능합니다. 잠금 파일이 있으면 고정된 종속성을 사용하고 설치하며 내가 틀리지 않은 경우 pipenv 수행합니다.

추상 종속성을 사용하는 유일한 경우는 배포용(기본적으로 라이브러리용) 프로젝트를 패키징할 때입니다. 이 경우 고정된 종속성을 원하지 않기 때문입니다.

@vlcinsky 아직 정리, 수정 또는 확장해야 할 몇 가지 사항이 있지만 Pipenv 또는 기타 문서 형식으로 전환하는 데 여전히 매우 열심입니다. 풀 리퀘스트를 보내는 데 관심이 있으십니까? 기사를 구체화하는 데 도움이 되었으면 합니다.

시와 관련하여 나는 개인적으로 전체적으로 팬이 아니지만 많은 올바른 일을 합니다. Pipenv 개발자가 사람들에게 알리고자 하는 몇 가지 모범 사례를 위반하기 때문에 Pipenv 문서에서 언급해서는 안 되지만 pypa-dev 또는 이와 유사한 토론이 열리는 경우 패키징 방식에 대한 완전한 그림을 제공하기 위해 언급해야 합니다. 생태계는 현재입니다.

시는 또한 더 많은 관심과 기여를 사용할 수 있습니다. 이것은 Pipenv를 포함한 커뮤니티에 가장 적합합니다. 실행 가능한 선택을 통해 사람들은 먼저 Pipenv 헤드에 들어가서 예상한 대로 되지 않는다고 불평하는 대신 선택에 가중치를 둘 수 있습니다. 라이브러리 간의 좋은 경쟁은 또한 Pipenv와 시가 모두 하는(완벽하지도 않은) 종속성 해결 측면에서 기술적인 개선을 촉진할 수 있습니다. 우리는 서로에게서 많은 것을 배울 수 있습니다.

@uranusjr 예, 명확히 밝혀진 사항이 거의 없으며 더 많은 청중과 공유할 가치가 있다고 생각합니다. 여러분의 도움을 진심으로 환영합니다.

"쌍 문서 초안"은 어떻습니까? 현시점에서는 2인의 소규모로 작업하는 것이 가장 효과적일 것이라고 생각합니다.

할 생각은 다음과 같습니다(1~2회 반복 가능).

• 정확히 어디에 게시할 수 있는지
• 문서 항목(기사, 섹션) 식별
• 각 항목의 범위와 목적을 명확히
• 개요에 동의
• 미해결 문제 식별
• 그들을 해결
• 문서를 작성
• 출판 (그리고 그것이 받아 들여지기를 바랍니다)

(토론된 내용을 기반으로) 스스로 작성하고 싶고 저를 리뷰어로 삼는다면 저는 불평하지 않을 것입니다.

다음 조치에 동의하기 위해 이메일로 연락 드리겠습니다.

@vlcinsky 또한 실시간 상호 작용을 선호하는 경우 PySlackers (Slack 작업 공간)에서 @uranusjr 로 사용할 수 있습니다. Pipenv에는 채널이 있습니다( #pipenv ).

@uranusjr 노력을 모은다는 뜻입니다. Python은 화물과 같은 좋은 패키지 관리자가 절실히 필요합니다. Python 생태계는 작업을 수행하는 표준 방법이 없기 때문에 다른 언어에 비해 창백합니다. 그리고 pipenv 는 도움이 되지 않을 것입니다.

저를 괴롭히는 것은 pipenv 자신을 the officially recommended Python packaging tool 로 광고한다는 것입니다. 그러나 패키지 도구가 아니라 사용자에게 오해의 소지가 있습니다. virtualenv 관리자와 결합된 종속성 관리자일 뿐입니다.

또한 패키지 도구인 카고, npm, yarn에서 영감을 얻었다고 하는데, 파이핑은 그렇지 않습니다.

그리고 여기에 pipenv 의 결함이 있습니다. 사람들은 requirements.txt vs setup.py 여전히 동일한 실수를 하기 때문에 물을 흐리게 만듭니다. 그 때문에 프로젝트는 setup.py 에 잘못 정의된 종속성과 함께 여전히 잘못 패키징됩니다. 이것이 바로 화물과 같은 프로젝트가 올바르게 수행한 것입니다. pipenv 와 같은 프로젝트는 그렇지 않은 반면 일관성을 보장하기 위해 프로젝트/애플리케이션 개발의 모든 측면을 처리합니다.

그리고 당신이 말할 때 :

Pipenv와 시가 둘 다 하는 것(완벽하지도 않음)

무슨 뜻이에요? 내가 본 바에 따르면, 그들의 의존성 관리자는 pipenv 제공하는 것보다 훨씬 더 탄력적입니다. 유일한 단점은 잘못 게시된 패키지로 인해 종속성 정보가 없는 PyPI JSON API를 사용한다는 것입니다.

어쨌든 말씀하신 것처럼 두 프로젝트가 서로 배울 수 있다고 생각합니다.

그리고 한 가지 더, 궁극적으로 pip가 Pipfile 처리한다면 pipenv의 미래는 어떻게 될까요? virtualenv 관리자 일뿐입니까?

시 종속성 관리자가 json API에 의존하는 경우 '잘못 게시된 패키지'로 인해 때때로 잘못될 뿐만 아니라 실제로 올바르게 해결할 수 있는 항목이 매우 제한적일 것입니다. 웨어하우스 json API는 이전 버전을 처리하는 경우에도 _가장 최근의_ 종속성을 게시하며, 이는 해당 정보가 있는 경우입니다. json api도 통합해서 사용했는데 빨라서 좋았는데 인프라팀에서 믿지 말라고 하더군요. 시작할 때 신뢰할 수 없는 출처에 의존하는 경우 탄력적이라고 ​​부르는 것은 다소 정직하지 않은 것 같습니다.

궁극적으로 문제는 현재 패키징이 작동하는 방식이기 때문에 설정 파일을 실행하는 종속성 그래프를 실제로 구축하는 것입니다. 주위에 방법이 없습니다. 내 컴퓨터에서 확인되는 종속성 그래프는 동일한 패키지에 대해서도 컴퓨터에서 확인되는 것과 다를 수 있습니다.

손을 흔들며 'pip가 pipfile을 읽을 수 있으면 pipenv를 virtualenv 관리자로 만들지 않습니까?'라고 말하기 쉽습니다. 아니요. Pipenv는 종속성 관리자입니다. 멱등성 환경을 관리하고 재현 가능한 잠금 파일을 생성합니다. 나는 당신이 그것을 흔들고 이 도구를 virtualenv 관리자로 축소하기 때문에 이것이 당신에게 사소해 보일 것이라는 것을 알고 있지만 그렇지 않습니다. 우리는 잠금 파일을 해결하고 귀하가 가지고 있지 않거나 사용하지 않는 Python 버전에 대한 마커를 포함하고 사용 가능한 상태로 유지하여 플랫폼 및 Python 버전 간에 정확하게 배포하고 재현할 수 있도록 합니다. 우리는 로컬 휠과 파일, vcs 리포지토리(그래프도 해결) 원격 아티팩트, pypi 패키지, 개인 인덱스 등을 처리하는 등 여러 해결 방법을 사용합니다.

하루가 끝나면 pip _will_은 pipfiles를 처리합니다. 그것이 계획입니다. 형식이 생성된 이후로 계획이었습니다. 그러나 이는 '하지만 pip가 요구 사항 파일을 처리할 수 있는 경우는 어떻습니까?'라는 질문과 동일합니다. 질문은 기본적으로 동일합니다. Pip은 해당 형식을 설치할 수 있습니다. 그것은 우리가 파일을 설치한다는 것 외에 내가 설명한 기능과 실제로 관련이 없습니다(그런데 pip를 사용하여).

@techalchemy

웨어하우스 json api는 이전 버전을 처리하는 경우에도 가장 최근의 종속성을 게시하며, 이는 해당 정보가 있는 경우입니다.

이것은 잘못된 것입니다. https://pypi.org/pypi/{project}/{release}/json 를 호출하여 특정 버전 종속성을 얻을 수 있습니다. https://pypi.org/pypi/{project}/json 호출하면 마지막 종속성만 얻을 수 있지만 실제로는 올바른 종속성 세트를 얻을 수 있습니다.

그리고 파이썬 프로젝트의 패키징/퍼블리싱 부분은 정말로 개선되어야 합니다. 왜냐하면 그것이 JSON API를 안정적으로 사용할 수 있게 해주기 때문에 결국 모두에게 이익이 될 것이기 때문입니다.

멱등성 환경을 관리하고 재현 가능한 잠금 파일을 생성합니다.
우리는 잠금 파일을 해결하고 귀하가 가지고 있지 않거나 사용하지 않는 Python 버전에 대한 마커를 포함하고 사용 가능한 상태로 유지하여 플랫폼 및 Python 버전 간에 정확하게 배포하고 재현할 수 있도록 합니다.

poetry 마찬가지입니다. 그리고 pipenv (pip-tools 사용)와 동일한 해결 방법을 사용하도록 JSON API를 사용하지 않도록 할 수 있습니다. https://github.com/sdispater/poetry/issues/37#issuecomment -379071989를 참조 pipenv 보다 더 탄력적일 것입니다(https://github.com/sdispater/poetry#dependency-resolution )

@zface 마지막으로 이 말을 하겠습니다. 계층 구조에서 더 높은 곳으로 가져가십시오. Pipenv는 공식적으로 권장되는 Python 패키징 도구라고 자칭하지 않습니다. 이기 때문 이라고 합니다. 부적절하다고 생각되면 Pipenv를 추천하는 담당자에게 알려주십시오 . Pipenv dev에 이러한 것들을 넣지 마십시오. 이것은 불만을 제기할 수 있는 잘못된 장소이며, 여기에서 불만에 대한 해결책을 얻을 수 없습니다. 기술적인 질문에 대한 더 나은 답변을 얻을 수도 있습니다. 이것은 Python 패키징 도구 및 Python 패키징이 수행되는 방식에 대한 토론 게시판이 아니라 Pipenv의 문제 추적기입니다.

Pipenv는 해결을 위해 pip-tools에만 의존하지 않습니다. 이해 부족을 보여주는 하나의 라이너로 소프트웨어를 줄이는 것을 중단하십시오. 나는 PyPI API가 어떻게 작동하는지 아주 잘 알고 그것을 구현한 팀과 직접 이야기했습니다.

이것은 단지 명백한 잘못,

이런 종류의 태도는 여기에서 환영받지 못합니다. 우리가 말하는 내용을 이해하지 못한다고 가정하지 마십시오. 예의를 지켜주세요.

여전히 pipenv(https://github.com/sdispater/poetry#dependency-resolution)보다 탄력적입니다.

Pipenv는 현재 종속성 그래프를 평면화하지 않습니다. 나무가 평평해진 한 가지 특정 문제를 지적하고 전체 도구가 더 좋고 더 탄력적이라고 ​​주장하는 것은 어리석은 일입니다. 당신은 단순히 pipenv를 모욕하고 시를 홍보하기 위해 여기 있다는 것을 반복해서 증명하고 있습니다. 이 행동은 환영할 수 없습니다.

나는 그 토론이 pipenv 주위의 "좋은 관행"을 대문자로 쓰려고 했던 주제에서 벗어났다는 데 동의합니다.

하지만,

[...] 여전히 requirements.txt 대 setup.py에서 이전과 같은 실수를 범할 것입니다. 그 때문에 프로젝트는 setup.py에 잘못 정의된 종속성과 함께 여전히 잘못 패키징됩니다.

저는 이 의견을 공유합니다. 새로운 개발자가 자신의 Python 코드를 성공적으로 패키징하는 것은 실제로 복잡하고 너무 복잡하며 많은 온라인 문서를 읽어야 합니다.
그러나 이를 완전히 처리하는 것은 pipenv 또는 기타 패키지 종속성에 달려 있지 않습니다. 우리는 역사를 다시 쓸 수 없습니다. 커뮤니티로서 우리는 파이썬 도구 체인을 단계적으로 현대화하는 방법을 찾아야 합니다.

그리고 pipenv(그리고 아마도 시)는 아주 좋은 진전입니다.

한쪽에서 애플리케이션을 위해 Pipfile 를 유지하고 다른 쪽에서 라이브러리를 위해 setup.py 를 유지해야 하는 것은 쉬운 일이 아닙니다. 많은 단어와 긴 기사 및 모범 사례 가이드로 아무리 어렵게 설명하더라도 내용이 너무 복잡합니다. 나는 그것이 현재와 같다는 것에 전적으로 동의하지만, 그것이 우리가 더 좋고 안전한 방법을 상상하는 것을 방해해서는 안됩니다.
결국, 저는 개발자로서 저를 돕고 제 삶을 최대한 쉽게 만들 수 있는 단일 도구, 아마도 두 가지 다른 모드를 원합니다.

하지 만 일부를 추출하는 방법으로 그들의 있어야 requirements.txt/Pipfile 하는 Pipfile 인식 래퍼 arround를 '쉽게 setup.py'의 일종으로 제안하는 등의 PBR 등의 libs와에서 install_requires ,하지를 pbr이 가져오는 모든 원치 않는 동작과 이를 수행하는 전용 setuptools 래퍼에서 패키지합니다.

그래서 우리는 각각의 세상에서 더 나은 것을 가질 수 있을 것입니다.

• Pipfile 를 유지하기 위한 pipenv(라이브러리와 애플리케이션 모두에서 버전 관리됨)
• Pipfile.lock 를 유지하기 위한 pipenv(응용 프로그램에 대해서만 버전이 지정됨)
• 하나는 Pipfile 을 install_requires 에 주입하는 작업인 첫 번째 수준 종속성이 되는 이 마법 래퍼 패키지( pipfile_setuptools , install_requires_pipfile ?)를 사용합니다.

이것은 pipenv 와 관련이 없지만 여전히 일반 Pipfile 파서 라이브러리가 필요한 또 다른 프로젝트입니다. 어떻게 생각하나요?

@gsemet 내 이해에서 PyPA는 대신 flit이 이끄는 pyproject.toml로 채우려고 했습니다. Pipfile을 소스 형식으로 사용하기 전에 이에 대해 먼저 (pypa-dev 또는 distutils-sig에서) 이야기해야 합니다. Pipfile(및 잠금 파일)을 구문 분석하는 경우 pypa/pipfile (Pipenv 공급업체에서 핵심 구문 분석 논리를 제공함)에서 처리됩니다.

편집: 메일링 리스트 중 하나에서 이에 대한 토론을 시작하기로 결정했다면 저에게 메시지를 보내주십시오. Python 패키징 배포의 두 부분을 함께 가져올 수 있는 몇 가지 아이디어가 있습니다.

PyPa는 Pipfile 도 지원하지만 pyproject.toml (PBR에서 setup.cfg 역할을 수행함)에 선언된 종속성을 보는 것이 조금 슬프다는 것을 인정해야 합니다.

flit 및 pipfile에 대한 포인터를 주셔서 감사합니다. 가벼워 보이는 Kennethreitz 의

PBR의 setup.cfg는 공식 문서(예: data_files )에 비해 더 완벽해 보이며 이미 여러 도구(flake8, pytest, ...)와 공유된 파일을 재사용하면 동일한 파일을 사용할 수 있으므로 개수를 줄일 수 있습니다. 파이썬 프로젝트의 루트에 있는 파일)