Pipenv: setup.py install_requires 및 Pipfile을 동기화 상태로 유지하는 방법

pipenv에 사용할 수 있는 python API가 있습니까? 프로젝트에서 작업할 때 수동으로 목록을 업데이트하지만 다음이 좋을 수 있습니다.

from setuptools import setup
from pipenv import find_install_requires

setup(
    # ...
    install_requires=find_install_requires()
    # ...
)

이 함수는 pipfiles [packages] 섹션의 키 목록을 반환하기만 하면 됩니다. 이미 도우미 기능을 사용하여 이 기능을 달성할 수 있다고 생각합니다. 하지만 이것이 pipenv의 일부라면 좋을 것이므로 우리 모두가 그것을 구현할 필요가 없습니다.

Pipenv 의 Pipfile 구문 분석을 지원하는 구현인 Pipfile은 다음과 같은 작업에 도움이 될 수 있습니다.

import pipfile
pf = pipfile.load('LOCATION_OF_PIPFILE')
print(pf.data['default'])

그러나 나는 이것을 권장하지 않거나 setup.py의 Pipenv에 따라 다릅니다. pipenv 가져오기(또는 pipfile )는 사용자가 패키지를 설치하기 전에 실제로 설치해야 함을 의미하며 Pipenv와 같은 도구는 설치하지 않고 엿보기( setup.py egg_info )를 이겼습니다. 작동하지 않습니다. setup.py는 Setuptools에만 의존해야 합니다.

중간 솔루션은 Pipfile을 기반으로 텍스트 파일을 자동으로 동기화하는 bumpversion 과 유사한 도구를 작성하는 것입니다. 이 파일을 패키지와 함께 배포하고 setup.py에서 읽으십시오. 그런 다음 CI 또는 커밋 후크를 사용하여 파일이 항상 동기화되어 있는지 확인합니다.

예, 좋은 지적은 나를 무시합니다.
아마도 "pipenv install"이 동기화를 수행할 수 있습니까?

2018년 1월 8일 월요일 오후 5:04 Tzu-ping Chung 알림 @github.com
썼다:

Pipfile https://github.com/pypa/pipfile , 다음을 지원하는 구현
구문 분석은 다음과 같이 도움이 될 수 있습니다.

핍 파일 가져오기
pf = pipfile.load('LOCATION_OF_PIPFILE')
인쇄(pf.data['기본'])

그러나 나는 이것을 권장하지 않거나 setup.py의 Pipenv에 따라 다릅니다.
pipenv(또는 pipfile) 가져오기는 사용자가 실제로 설치해야 함을 의미합니다.
패키지를 설치하기 전에 Pipenv와 같은 도구가
설치하지 않고 엿보기(setup.py egg_info)가 작동하지 않습니다. 그만큼
setup.py는 Setuptools에만 의존해야 합니다.

중간 해결책은 범프 버전과 유사한 도구를 작성하는 것입니다.
텍스트를 자동으로 동기화하는 https://github.com/peritus/bumpversion
Pipfile 기반 파일입니다. 이 파일을 패키지와 함께 배포하고 읽으십시오.
setup.py에서. 그런 다음 CI 또는 커밋 후크를 사용하여 파일이 항상
동기화.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/pypa/pipenv/issues/1263#issuecomment-355889369 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/ALMBlmmV52kdIL9D4zlMJoQh2JpaGdDbks5tIa_jgaJpZM4RRu3v
.

@uranusjr 은 여기에서 내 가정을 테스트하지만 setup.py의 setup_requires에 pipenv를 추가하고 setuptools 명령으로 pipenv 가져오기를 지연하는 것이 가능하지 않을까요? 아니면 나쁜 습관으로 간주됩니까?

@Korijn 그 자체는 아닐 수도 있지만 현재 모범 사례는 각 Python 프로젝트에 대해 별도의 virtualenv를 사용하는 것이므로 사용자가 각 프로젝트에 대해 Pipenv 사본을 설치해야 하므로 매우 직관적이지 않습니다. Pipenv는 한 번만 설치해야 하며(일반적으로 전역적으로) 프로젝트의 virtualenv 내부가 아니라 관리를 위해 프로젝트의 virtualenv 외부에서 사용됩니다.

그렇다면 문제의 종결로 이어진 이에 대한 해결 방법은 무엇입니까? Pipfile 와 setup.py 의 종속성을 모두 추적할 수 있는 방법이 없습니까? 문제를 우회하는 모범 사례가 있습니까?

설치 프로그램에 배포되거나 배포되는 응용 프로그램의 경우 Pipfile만 사용합니다.

setup.py를 사용하여 패키지로 배포되는 응용 프로그램의 경우 모든 종속성을 install_requires에 넣습니다.

그런 다음 pipenv install '-e .' 를 실행하여 Pipfile이 setup.py에 종속되도록 합니다.

[업데이트 2019-08-23] 요즘에는 dev 패키지를 Pipfile에 보관하고 런타임 종속성만 setup.py에서 실행됩니다.

@Korijn의 접근 방식이 여기에서 모범 사례라고 생각합니다. Pipfile(및 requirements.txt)은 애플리케이션용입니다. setup.py는 패키지용입니다. 그들은 다른 목적을 수행합니다. 동기화해야 한다면 잘못하고 있는 것입니다(IMO).

@uranusjr 문서에 따르면 아닙니다.

Pipenv는 모든 패키징 세계(번들러, 작곡가, npm, 화물, 원사 등)의 최고를 Python 세계로 가져오는 것을 목표로 하는 도구입니다. Windows는 우리 세계에서 일류 시민입니다.

프로젝트에 대한 virtualenv를 자동으로 생성 및 관리하고 패키지를 설치/제거할 때 Pipfile에서 패키지를 추가/제거합니다. 또한 결정적 빌드를 생성하는 데 사용되는 항상 중요한 Pipfile.lock을 생성합니다.

어쩌면 내가 이해하지 못하는 것일 수도 있습니다. 귀하의 진술에 대해 자세히 설명해 주시겠습니까?

내가 이해한 바로는 pipenv 는 PHP용 작곡가와 유사한 완전한 종속성 관리 시스템이지만 그렇지 않다는 것을 깨닫기 시작했습니다. 특히 pipenv 는 Pipfile 및 Pipfile.lock이 있지만 setup.py에 install_requirements가 없는 종속성의 종속성을 설치하지 않기 때문입니다.

@vascowhite 귀하가 묻는 질문은 pipenv에 관한 것이 아니라 python 패키징 도구 간의 근본적인 분리에 관한 것입니다. Python 워크플로에서 setup.py 파일은 배포 가능한 패키지의 설치 종속성을 선언하는 데 사용됩니다. 따라서 requests 와 같은 패키지가 있고 cffi 가 설치된 사람들에 따라 달라지는 경우 setup.py 에서 이를 선언하여 사람들이 pip install requests 를 실행할 때

요구 사항 파일과 같은 Pip 파일은 재귀적으로 탐색되지 않습니다. 대신 개발 중인 프로젝트의 모든 종속성을 제어하는 ​​단일 pipfile이 있습니다. 요점은 이전 워크플로가 고정된 요구 사항의 평면화된 목록을 생성한 반면 Pipfiles는 최상위 요구 사항을 포함하고 가능한 경우 고정 해제를 선호한다는 것입니다. 패키지를 설치할 때 setup.py 의 요구 사항은 다른 요구 사항에도 맞는 최상의 일치 로 재귀적으로 해결됩니다.

따라서 Pipfiles가 재귀 적으로 해결되지 않는 이유를 알고 싶다면 파이썬에서 사용되는 방식이 아니기 때문입니다. pipenv install 를 실행하려면 궁극적으로 setuptools 로 설치할 수 있는 대상이 필요합니다. 즉, 설치 요구 사항이 설정 파일에 정의되어 있습니다.

@techalchemy 비슷한 답변을 중간에 하고 있었는데 😂 (모두 삭제)

나는 또한 @vascowhite 당신이 요구하는 것이 사실 이상하지 않다는 점에 주목하고 싶습니다. Pipfile과 잠금 파일을 모두 사용할 수 있으므로 두 가지 별개의 워크플로를 조정할 수 있습니다. 이상적인 세계에서 Pipfile은 setup.py의 install_requires 를 대체하고 가상 종속성을 지정하는 데 사용되는 반면 잠금 파일은 이를 기반으로 하는 구체적인 종속성 세트를 생성하는 데 사용되어 requirements.txt를 대체합니다.

그러나 Python의 패키징 시스템은 현재 로서는 이상적이지 않으며 이것이 일어나기 전에 많은 정리가 필요할 것입니다. 젠장, Pipenv는 이미 현재 종속성을 처리하는 데 어려움을 겪고 있습니다(ps 누구의 잘못도 아님). 그렇게 사용하는 경우 가장 단순한 프로젝트가 아닌 한 거의 작동하지 않을 것입니다.

그래도 희망은 잃지 않았습니다(적어도 내 것은 아님). 이 문제와 관련하여 많은 PEP가 제안되고 구현되었으며, setup.py 및 requirements.txt가 모두 엄격하고 선언적인 형식으로 이동하면서 상황이 올바른 방향으로 가고 있다고 생각합니다. 생태계가 너무 크기 때문에 상황이 느리게 움직여야 하지만(또는 Python 3.0 참조) 실제로 움직이고 있습니다.

@sweet_ssssssss @sssssssssss 맞아요
두 분 모두 명쾌한 답변을 해주셔서 감사합니다. 그들은 제 마음속에 몇 가지를 바로잡아 줍니다. 문서가 Pipenv가 할 수 있는 일을 설명하는 것 이상이며 부분적으로 내 혼란의 원인인 것 같습니다. 내 혼란의 대부분은 나에게 달려 있습니다. :)

PHP에서 왔기 때문에 파이썬으로 패키징하는 것이 혼란스러웠습니다. Composer는 그에 비해 산들 바람입니다. 나는 파이썬을 개발하기가 훨씬 쉽고 그것을 사용하는 것을 좋아합니다. 상황이 개선되기를 바랍니다. 여러분과 Kenneth Reitz와 같은 사람들의 노력을 기울일 것이라고 확신합니다.

위에서 언급한 제 조언을 따르면 setup.py와 pipenv를 완벽하게 조화시킬 수 있습니다. 모든 소란을 얻을 필요가 없습니다. :)

나만 헷갈린게 아닌거같다 #1398

내가 할 수있는 것보다 훨씬 더 잘 넣어 :)

setup.py pipenv 를 사용하는 방법에 대한 정보를 얻기 위해 여기에 왔습니다. 토론에 내 0.2센트를 추가합니다.

setup.py 처럼 보이는 파이썬 패키지가 있습니다.

 setup(                                                                                                     
    name='my-pkg-name',                                                                             
    packages=find_packages(),                                                                              
    install_requires=[...],
    extras_require={
        'develop': ['click']
    },
    entry_points={
        'console_scripts': [
            'my-pkg-name-cmdline = my-pkg-name.cli:tool'
        ]
    }

보시다시피 저는 빌드 및 배포와 같은 작업의 스크립트 진입점에서 click 를 사용합니다.

$ my-pkg-name-cmdline build 를 실행할 때 pipenv install --dev click 가 설치된 것을 찾을 수 없습니다. 작동하게 하려면 pipenv shell/exit 를 조작해야 합니다. 이 부분에는 아직 거친 부분이 있는 것 같습니다.

따라서 패키지에 pipenv 를 사용하지 않으면 +1입니다.

이 시나리오에서 pipenv run my-pkg-name-cmdline build 를 호출할 것으로 예상됩니다.

@Korijn 나는 여전히 올바른 워크플로에 대해 확신하지 못합니다(여전히 pipenv로 약간 실험 중입니다).

아직까지는 저에게 효과가 있는 것으로 보이는 워크플로는 다음과 같습니다.

(starting from scratch)
1- pipenv --three
2- pipenv install [--dev]
3- pipenv install -e . (install application locally)
4- pipenv shell (to enter the virtualenv)

이제 명령줄에서 패키지 빌드 click 스크립트를 실행할 수 있습니다.

응용 프로그램을 로컬로 설치(3단계) 하기 전에 virtualenv(4단계)에 들어가면 작동하지 않습니다.

아마도 pipenv shell 전에 패키지를 설치해야 한다는 것을 기억하도록 내 두뇌를 다시 연결해야 할 것입니다( virtualenv 를 사용하는 동안 virtualenv가 활성화된 패키지를 설치해야 함).

@apiraino 나는 당신이 바로 여기에서 물건을 얻지 못한다고 생각합니다. 패키지에서 (가져오기) 클릭을 사용하려면 대신 install_requires 에 넣어야 합니다. 그러면 패키지를 설치하는 사람들(자신 포함)도 클릭이 설치될 수 있습니다. extras_require['dev'] 에 넣는 것은 선택적 종속성을 의미합니다. 즉, 패키지가 없어도 패키지가 작동할 수 있지만 이러한 추가 기능을 설치하면 특정 추가 기능을 제공할 수 있습니다.

이 토론은 실제로 더 이상 Pipenv와 아무 관련이 없습니다. 이 문제를 StackOverflow 또는 Python 관련 메일링 리스트와 같은 보다 적합한 포럼에 가져오도록 제안합니다.

@Korijn pipenv install '-e .' 는 setup.py의 install_requires에 나열된 모듈을 반영하지 않는 Pipfile $를 생성합니다.

이것은 여전히 ​​pipenv 9.0.3의 경우입니다.

setup.py 의 install_requires에서 Pipfile 를 생성하려면 어떻게 해야 합니까?

따옴표를 사용하지 마십시오

따옴표 사용을 중단했습니다. 그러나 setup.py 의 install_requires 섹션에서 deps를 포함하는 Pipfile 생성되지 않습니다.

@benjaminweb 오늘도 똑같은 일로 혼란스러웠다. 그러나 현재 행동이 수정될 수 있다고 생각하기 시작했습니다.

@techalchemy 위에서 언급한

Pipfile에는 최상위 요구 사항이 포함되어 있으며 가능한 경우 고정 해제를 선호합니다. 패키지를 설치할 때 setup.py의 요구 사항은 다른 요구 사항에도 맞는 최상의 일치 항목으로 재귀적으로 해결됩니다.

https://github.com/pypa/pipenv/issues/1263#issuecomment -362600555에 언급된 워크플로를 사용하는 경우 기존 Pipfile이 없는 프로젝트에서 pipenv install '-e .' 를 실행할 때 pipenv는 다음을 사용하여 새 Pipfile을 생성합니다. 다음과 같은:

[packages]

"e1839a8" = {path = ".", editable = true}

이 경우 virtualenv에 설치하도록 명시적으로 요청한 유일한 패키지는 패키지 자체(예: ".")이므로 "." Pipfile의 ( [packages] )에 추가됩니다. 마찬가지로 pipenv install requests 하면 요청의 setup.py에서 install_requires 종속성이 프로젝트의 Pipfile에도 추가되지 않습니다.

그러나 다음에 패키지 설치 단계가 발생하면 install_requires 종속성 이 패키지에 대한 종속성 해결의 일부로 설치됩니다.

Pipfile과 달리 Pipfile.lock은 전체 virtualenv에 대한 모든 정확한 종속성을 기록합니다. 여기에는 특정 버전에 잠겨 있는 install_requires 종속성이 포함되어야 합니다. 생성된 Pipfile.lock을 보면 install_requires 종속성이 나열되어 있습니다.

이것이 어떻게 작동할지 완전히 오해하고 있을 수 있습니다. @techalchemy 또는 @uranusjr 이 이것이 올바른 사고 방식인지 확인할 수 있을까요?

당신의 생각은 나와 일치합니다. 또한 최근 Setuptools의 발전과 Flit과 같은 도구 를 사용하여 멋진 TOML 형식으로 패키지의 종속성을 지정할 수 있다는 점도 언급하겠습니다(setup.py의 요구 사항 문자열 대신). Pipfile 대신 pyproject.toml에서 지정하기만 하면 됩니다.

@uranusjr 그것은 Pipfile이 Setuptools 또는 Flit과 같은 패키징 도구(setup.py 또는 pyproject.toml을 통해)에 의해 아직 캡처되지 않은 경우에만 프로젝트 종속성을 명시적으로 나열하면 된다는 말씀처럼 들립니다.

예를 들어 setup.py가 다음과 같은 경우:

install_requires=['A'],
extras_require={
    'dev': ['B'],
},

그런 다음 Pipfile에는 다음만 필요합니다.

[[source]]

url = "https://pypi.python.org/simple"
verify_ssl = true
name = "pypi"


[packages]

"e1839a8" = {path = ".", editable = true}


[dev-packages]

"e1839a8" = {path = ".", extras = ["dev"], editable = true}

pipenv install 를 실행하면 프로덕션용 종속성 A가 설치되고 pipenv install --dev 는 개발용 종속성 A 및 B가 설치됩니다.

누군가가 이미 Setuptools 또는 Flit을 사용하고 있다면 [packages] 또는 [dev-packages] 아래의 Pipfile에 종속성을 추가해야 하는 이유가 있습니까? 요청 을 예로 들면 개발 종속성이 Pipfile에 [dev-packages] 아래에 명시적으로 나열되는 이유가 명확하지 않지만 install_requires 및 test_requirements 종속성은 모두 설정에서 캡처됩니다. .파이.

Pipfile에 종속성을 명시적으로 추가 해야 하는 유일한 이유는 Setuptools 또는 Flit을 사용 하지 않는 경우인 것 같습니다. 이 올바른지? 이것이 사실이 아닌 이유가 있습니까?

그냥 개인적인 취향이라고 생각합니다. extras_require[dev] 에 개발 종속성을 나열하는 것은 단지 관례일 뿐입니다. dev-packages OTHO는 잘 정의된 키입니다. extras_require[dev] 는 또한 모든 사용자가 pip install package[dev] 를 사용할 수 있도록 하며 이는 관리자가 좋아하지 않을 수 있습니다. 나는 다른 사람 중 하나를 선호하는 사람들을 이해할 수 있습니다.

packages 에 관해서는 아니오, 실제로 install_requires IMO보다 더 합리적인 시나리오는 없습니다. 나는 사람들이 창의적인 사용법을 생각해 낼 것이라고 확신합니다.

이 문제가 종료된 이유는 무엇입니까?

@JulienPalard 몇 가지 이유로 폐쇄되었습니다.

1. Pipfiles 및 setup.py 파일은 실제로 동기화를 유지하기 위한 것이 아닙니다. 그 자체로 세부 사항을 논의하는 링크된 기사가 많이 있다고 생각하지만 tl;dr Pipfile 는 대략적으로 동일합니다. 최상위 requirements.txt
2. 프로젝트(현재 디렉토리)에서 setup.py 가 관리되는 virtualenv로 확인되도록 하려면 워크플로는 pipenv install -e . 가 됩니다. -- 이렇게 하면 Pipfile 에 단일 항목이 추가됩니다. install_requires Pipfile.lock 에 넣습니다. install_requires 변경으로 인해 virtualenv를 최신 내용으로 업데이트하려면 최신 버전의 pipenv lock && pipenv sync 와 동일한 pipenv update 를 실행해야 합니다.

도움이 되기를 바랍니다.

실제로 Pipfile 는 requirements.txt 와 비슷합니다. requirements.txt 는 모든 패키지를 플랫 방식으로 지정하는 반면 Pipfile & setup.py 엔트리 레벨 종속성만 필요합니다. Pipfile.lock 및 requirements.txt 에 유사한 정보가 있습니다.

추가로 구현할 수 있지만 현재 사용 사례를 다루는 POC 동기화 스크립트를 만들었습니다.
https://gist.github.com/iddan/f190c3c7d54f4fc4655da95fb185e641

@iddan 그것은 본질적으로 내가 말했던 것입니다. 이러한 각 항목은 종속성의 최상위 목록을 나타내지만 하나는 _응용 프로그램 설치_( setup.py )용이고 다른 하나는 _개발용_( Pipfile ).

setup.py 를 사용하는 전자의 경우 $#$3 requirements.txt #$ 에서와 같이 개방형 또는 완전히 고정된 종속성을 선언하는 동일한 옵션이 있지만 대부분의 사람들은 여기에서 개방형 종속성 고정을 사용합니다. Pipfile 엄격하거나 느슨한 핀도 지정할 수 있지만 이를 종속성 그래프의 _평평하지 않은_ 목록으로 유지하는 것이 좋습니다. 다시 말하지만, 이 두 가지 모두 requirements.txt 파일에서도 완전히 유효하다는 점을 강조하고 싶습니다. 이것이 제가 지속적으로 응용 프로그램과 라이브러리 간의 책임 분리를 강조하는 이유입니다. 모든 강연과 모든 튜토리얼, 그리고 PyPA에서 제공하는 모든 메시지에서 이것이 강조되는 것을 듣게 될 것입니다.

Pipfile.lock 및 requirements.txt 는 같은 것이 아닙니다. Pipfile.lock requirements.txt 를 생성할 수 있지만 중개자 Pipfile 를 사용하지 않고 요구 사항 파일에서 잠금 파일을 직접 생성할 수 없습니다. Pipfile.lock 는 전이적 클로저 를 나타내고 종속성 해결을 수행하기 위해 항상 중개자 Pipfile 가 필요하기 때문입니다.

원래 질문에 관해서는 단순히 해당 디렉토리를 편집 가능한 경로로 포함하는 것 외에는 setup.py 파일을 Pipfile 와 동기화된 상태로 유지해야 할 이유가 없습니다. pipenv lock 를 실행하면 setup.py 파일의 종속성이 자동으로 해결됩니다. 특정 사용 사례 @iddan 또는 설정 파일에 다시 쓰기 위해 특별한 파서가 필요한 이유에 대해 잘 모르겠지만 setup.py 대 요구 사항에 대한 Donald Stufft의 기사를 읽고 싶을 것입니다. txt 를 참조하거나 차이점과 Pipenv에 구체적으로 적용되는 방법에 대해 관리자 중 한 명이 이 설명 을 참조합니다.

제 사용 사례는 K Health에 독립 실행형 서비스와 패키지로 사용할 수 있는 내부 패키지가 포함된 저장소가 있다는 것입니다. 따라서 패키지 소비자와 서비스의 개발/배포 구성 간의 최상위 종속성을 공유하고자 합니다. 우리는 의존성을 관리하기 위해 Pipenv를 사용하고 있기 때문에 Pipfile 의 출력을 setup.py 로 얻는 것이 좋을 것입니다.

#2148의 변형처럼 들립니다(Requirements.txt를 Pipfile로 대체).

그러나 이것은 setup.py 에 관한 것입니다.

이것. 문제. 해야한다. 아니다. 이다. 닫은.

이 문제는 종료되었습니다.

1. Pipenv는 패키징 도구가 아닙니다 .
2. Pipenv에 패키징 기능을 포함하지 않기로 결정했습니다.
3. 패키지 개발 중에 Pipenv를 사용하여 개발 종속성을 관리하는 방법이 명확해졌습니다.
4. Pipfile은 개방형 표준입니다. Pipfile 형식을 기반으로 패키징 도구를 쉽게 구축할 수 있습니다. Pipenv가 그렇게 하지 않기로 결정했다고 해서 자신 이 그렇게 하는 것을 배제하는 것은 아닙니다.

정말 이만큼 신경이 쓰이면 도구를 직접 만들어주세요. 이 문제에 대한 기대가 매우 높기 때문에 여기에 솔루션을 게시하면 관심을 끌기가 어렵지 않을 것이라고 생각합니다. 그리고 견인력으로 PyPA는 Pipenv와 마찬가지로 패키징 가이드에서 이를 추천할 수 있습니다. 그러나 먼저 실제로 도구를 빌드해야 합니다.

또한 프로젝트 관리자에게 정중하게 대하는 방법을 배우십시오. 참조를 위해 행동 강령을 참조하십시오. 우리는 생산적인 토론을 하게 되어 기쁩니다. 그러나 우리는 자원 봉사자이며 단순히 개인의 소원을 따르기 위해 여기에 있는 것이 아닙니다. 당신이 그것을 관리할 수 없다면, 게시를 귀찮게하지 마십시오.

더 이상의 논의를 방지하기 위해 이 문제를 잠그는 것이 좋습니다. 요점을 분명히 했다고 생각합니다.

한 가지만 잘하면 된다!

안녕하세요 여러분,

@Korijn 나는 당신이 extra_requires를 사용하여 setup.py를 Pipfile과 동기화하는 방법을 설명하는 부분을 읽었습니다.

나는 그것을 시도하고 Pipfile.lock의 dev 섹션에 extra_require 패키지가 없다는 것을 알아차렸습니다. 따라서 빈 환경에 소스 코드가 있고 pipenv install --dev 를 수행할 때 Pipfile.lock에는 extra_require 요구 사항이 없기 때문에 pipenv install_require 에만 패키지를 설치합니다.

setup.py

import os  # noqa: D100
from setuptools import setup, find_packages


def read(fname):
    """Read a file and return its content."""
    with open(os.path.join(os.path.dirname(__file__), fname)) as f:
        return f.read()


setup(
    name='auditor_client',
    version='0.0.0',
    description='Auditor client package',
    long_description=read('README.md'),
    packages=find_packages(exclude=['tests']),
    install_requires=['requests==2.9.1'],
    extras_require={'dev': ['flake8', 'flake8-docstrings', 'pytest', 'coverage', 'tox']},
    setup_requires=["pytest-runner"],
    tests_require=["pytest"]
)

핍파일

[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[packages]
"e1839a8" = {editable = true, path = "."}

[requires]
python_version = "3.6"

[dev-packages]
"e1839a8" = {editable = true, extras = ["dev"], path = "."}

Pipfile.lock

{
    "_meta": {
        "hash": {
            "sha256": "e58b833e497814c83a2f0b93ad21d33a2af8b72721b20e9607a6c9135978422d"
        },
        "pipfile-spec": 6,
        "requires": {
            "python_version": "3.6"
        },
        "sources": [
            {
                "name": "pypi",
                "url": "https://pypi.org/simple",
                "verify_ssl": true
            }
        ]
    },
    "default": {
        "e1839a8": {
            "editable": true,
            "path": "."
        },
        "requests": {
            "hashes": [
                "sha256:113fbba5531a9e34945b7d36b33a084e8ba5d0664b703c81a7c572d91919a5b8",
                "sha256:c577815dd00f1394203fc44eb979724b098f88264a9ef898ee45b8e5e9cf587f"
            ],
            "version": "==2.9.1"
        }
    },
    "develop": {
        "e1839a8": {
            "editable": true,
            "path": "."
        },
        "requests": {
            "hashes": [
                "sha256:113fbba5531a9e34945b7d36b33a084e8ba5d0664b703c81a7c572d91919a5b8",
                "sha256:c577815dd00f1394203fc44eb979724b098f88264a9ef898ee45b8e5e9cf587f"
            ],
            "version": "==2.9.1"
        }
    }
}

Pipfile.lock이 extra_require dev 패키지를 추적한 올바른 동작이 아니어야 합니까?

예, 이것은 나에게 버그/제한으로 보입니다. 이에 대한 별도의 버그/이슈를 제출해야 합니다.

지금은 찾을 수 없지만 이 문제에 대해 트래커에서 열린 문제가 있는 것 같습니다. 문제를 열기 전에 기존 문제를 검색하십시오. 미리 감사드립니다 :)

이것은 버그가 아니며 pipfile에서 동일한 기본 항목을 여러 번 사용할 수 없습니다. dev 섹션과 기본 섹션에서도 종속성을 지정하면 기본 섹션이 무엇이든 상관없이 기본 섹션이 우선합니다.

나는 일반적인 사고 실험을 진행했지만 지금은 시간이 없으므로 무언가를 배포하고 개발 종속성이 충돌을 숨기고 있음을 알게 될 때 종속성 충돌과 놀라움을 유발할 수 있다는 점에 대해 말씀드립니다.

@techalchemy 이 경우 내 개발 종속성을 어떻게 관리할 수 있습니까? pipenv를 좋은 방법으로 사용하는 방법만 알고 싶습니다.

나는 내 자신의 프로젝트에 대해 이것에 대해 생각해 보았고 packages / dev-packages 구분이 실제로 필요하지 않다는 것을 깨달았습니다. packages {editable = true, extras = ["dev"], path = "."} 를 나열하는 것은 어떻습니까?

이 pipenv-setup 패키지를 확인하십시오

pipfile/lockfile을 setup.py에 동기화합니다.

$ pipenv-setup sync

package e1839a8 is local, omitted in setup.py
setup.py successfully updated
23 packages from Pipfile.lock synced to setup.py

$ pipenv-setup sync --dev 를 수행하여 개발 종속성을 추가 요구 사항에 동기화할 수 있습니다. 또는 대신 pipfile을 동기화하려면 $ pipenv-setup sync --pipfile

및 $ pipenv-setup check 는 검사만 수행합니다.

하나의 명령으로 모든 문제를 해결하세요 💯

pipenv-setup 패키지를 pipenv에 병합할 계획이 있습니까?

@peterdeme

pipenv-setup 패키지를 pipenv에 병합할 계획이 있습니까?

@uranusjr @techalchemy 위의 논의를 바탕으로 pipenv는 다소 다른 철학을 가질 수 있다고 생각합니다. 그러나 관리자가 동의한다면 pull 요청을 제출하고 pipenv-setup 통합을 시도하고 싶습니다.

내장된 json 모듈을 사용하여 항상 Pipfile.lock 를 구문 분석할 수 있습니다. setup.py install_requires 에 대한 non-dev 종속성을 추출합니다.
"default" 키는 version 숫자 및 markers 와 함께 패키지 이름의 중첩된 "dicts"를 포함합니다.
외부 수입품에 의존할 필요가 없습니다.

@Kilo59 나는 사람들이 이것을 하는 것을 보았다. 언급할 팁은 Pipfile.lock을 setup.py에 data_file로 포함하는 것을 잊지 마십시오(또는 MANIFEST.in에 포함). 고정된 종속성이 있는 잠금 파일용입니다. 반면에 pipfile은 Pipfile에서 의미 체계 버전 관리를 원할 경우 구문 분석하기가 쉽지 않습니다. 동일한 종속성 요구 사항이 여러 형식으로 표시될 수 있습니다.

@Madoshakalaka 덕분 에 도구가 잘 작동합니다!

나는 Setup.py의 종속성이 Pipfile의 프로젝트 종속성과 다르다는 다른 동료들과 동의합니다. 그러나 여전히 수동 작업 없이 동기화할 수 있는 프로그래밍 가능한 방법이 있다는 것은 시간을 절약할 수 있는 훌륭한 기능입니다. 또한 오타/일반적인 오류를 방지합니다.

검은색 setup.py도 좋은 터치였습니다.+1: