Pipenv: [질문] setup.py와 어떻게 통합하나요?

아래 코드로 이 작업을 수행할 수 있어야 합니다. 이것은 현재 프로젝트에서 Pipfile을 로드하고 pip 호환 목록에 종속성을 반환합니다.

from pipenv.project import Project
from pipenv.utils import convert_deps_to_pip

pfile = Project(chdir=False).parsed_pipfile
requirements = convert_deps_to_pip(pfile['packages'], r=False)
test_requirements = convert_deps_to_pip(pfile['dev-packages'], r=False)

추가 질문이 있으면 알려주세요 :)

위의 내용은 매우 유용합니다. setup.py install (또는 다른 것)이 실행되기 전에 가상 환경에 설치된 Pipenv에 따라 setup.py 에 문제가 발생했습니다. 내가 생각할 수 있는 이 문제에 대한 유일한 해결책은 Pipenv를 프로젝트로 벤더화하는 것인데, 이는 이상적이지 않은 것 같습니다. 또는 from pipenv... 가져오기를 실행하기 전에 setup.py를 해킹하여 Pipenv를 설치하는 것입니다. 잘못된. 누구든지 이것보다 더 나은 아이디어나 더 나은 솔루션이 있습니까?

Python 커뮤니티(PyPA 등)의 다른 사람들에게 ~괴롭힘~ 제안하여 Pipenv를 향후 Python 릴리스에 공식적으로 포함된 도구로 축복해야 합니까? 😄

setup_requires 에 pipenv 를 추가하는 것이 도움이 될까요? 불행해 보이는 install_requires 에 추가해야 할 수도 있습니다.

이 작업을 수행하지 마십시오.

@kennethreitz "이것"이 무슨 뜻인가요? setup.py, @nateprewitt 솔루션 또는 마지막 두 제안과의 통합을 의미합니까?

그렇다면 사용자는 pipenv가 설치되어 있어야 한다는 것을 어떻게 알 수 있습니까?

pipenv는 설치에 사용되는 도구이며 그 반대의 경우는 아니므로 setup.py에 필요하지 않습니다. Kenneth가 경고하는 것은 setup.py에서 pipenv를 가져오는 것입니다. 왜냐하면 이것은 cli 애플리케이션이고 문제를 일으킬 수 있기 때문입니다.

2017년 10월 17일 오전 9시 37분에 Iddan Ahhronson [email protected] 에서 다음과 같이 썼습니다.

그렇다면 사용자는 pipenv가 설치되어 있어야 한다는 것을 어떻게 알 수 있습니까?

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하세요.

그래서 setup.py에서 @nateprewitt 의 코드를 어떻게 사용할 수 있습니까?

@iddan : Pipenv 버전을 내 프로젝트 골격으로 공급하여 Pipenv 부트스트랩 문제를 해결하려고 했습니다(https://github.com/elgertam/cookiecutter-pypackage/blob/master/%7B%7Bcookiecutter.project_slug%7D %7D/setup.py). 지금까지는 문제가 없었지만 setup.py 를 사용하여 패키지를 설치하는 상황에서 테스트할 기회가 많았다고 말할 수는 없습니다.

setup.py를 로드할 때 CLI를 실행하지 않는 것에 대해 걱정하는 이유를 이해할 수 있지만, 내가 말할 수 있는 바에 따르면 내가 사용하고 있는 코드( @nateprewitt 의 게시물에서 복사하여 붙여넣기)는 상당히 안전합니다.

pip 에 Pipfile 형식을 이해하기에 충분한 내부 요소가 있으면 이 해킹이 더 이상 필요하지 않을 것이라고 생각합니다.

@iddan , 그 코드는 오로지 Pipfiles 종속성을 pip가 읽을 requirements.txt 스타일 형식으로 변환하기 위한 것입니다. Kenneth가 원본 게시물에서 무언가를 수정한 것 같지만 확실하지 않습니다.

Pipenv는 setup.py와 같은 배포용이 아닌 환경 관리 및 배포 도구를 위한 것입니다. Pipfile을 사용하고 있음을 문서화하고 설치 지침을 위해 pipenv.org에 연결하는 것이 좋습니다. 이것을 pip를 취급하는 것과 같은 방식으로 처리하십시오. 사용자가 새 Python 패키지를 설치할 때마다 pip를 설치할 것으로 예상되지는 않습니다.

나는 그것을 완벽하게 이해합니다. 내가 이해하지 못하는 것은 사용자가 이 스크립트를 사용하여 패키지를 다운로드하고 pipenv가 설치되어 있지 않을 때 어떤 일이 일어날 것이라고 예상하십니까?

@nateprewitt , 패키지를 배포하려는 경우( pip 를 사용하는 일반적인 방법을 통해) 종속성 목록의 복사본을 setup.py 또는 requirements.txt 에 유지해야 합니다. ? 내 Pipfile을 단일 정보 소스로 사용하고 싶었습니다.

명확히 하기 위해 첫 번째 응답의 코드는 실제로 setup.py 에서 사용되는 것이 아니라 빌드의 일부로 실행되어야 한다고 가정합니다.

내가 심하게 착각하지 않는 한, https://github.com/kennethreitz/pipenv/issues/209#issuecomment -278185133의 코드는 휠(=이진 dist)을 빌드하는 경우 사용하기에 안전하지만 다음과 같은 경우에는 그렇지 않습니다. 당신은 sdist (= 소스 dist)를 구축하고 있습니다.

휠의 경우 setup.py 는 패키지에 포함되지 않습니다(그러나 빌드 시 평가되고 메타데이터 파일은 수집된 정보를 기반으로 구성됨). 바퀴를 사용하면 setup.py 패키지가 설치되는 시스템에서는 실행되지 않고 빌드된 위치에서만 실행됩니다.

sdist를 사용하면 setup.py 가 실제로 설치 시스템에서 실행되므로 pipenv 를 사용할 수 있어야 합니다.

바로 이거 야. @tuukkamustonen , 내 특정 사용 사례는 sdist입니다. pip install 를 수행하기 전에 패키지 사용자가 pipenv 를 설치하도록 요구하고 싶지 않기 때문에 $ setup.py 외부에서 $ install_requires 를 파생시키는 데 어려움을 겪고 있다고 가정합니다. setup.py (즉, 수동으로 또는 빌드의 일부로)?

내가 올바르게 읽고 있다면 Kenneth와 다른 유지 관리자는 우리가 pytest 또는 일반 패키지 종속성처럼 Pipenv 를 프로젝트 종속성으로 취급하는 것을 원하지 않는다고 생각합니다. 이상적으로는 pip Pipenv 를 설치하고 업데이트해야 하는 것처럼 들립니다. 즉, pip 는 Python이 설치될 때 또는 virtualenv 가 생성됩니다. Kenneth가 "이 일을 하지 마십시오."

즉, @isobit 은 Pipfile 가 단일 정보 소스여야 한다는 제 생각을 반영했습니다. Pipfile을 선호하는 두 가지 강력한 사용 사례를 볼 수 있습니다(다른 것도 있음). 첫째, 빌드 환경을 설정하기 위해 Pipfile에 의존하는 CI/CD 파이프라인이 requirements.txt에 의존하는 것보다 훨씬 더 강력합니다. 둘째, 기여자가 Pipfile 기반 프로젝트를 맹목적으로 설치하려고 할 수 있습니다 python setup.py install 가 예상대로 작동하지 않으면 좌절할 수 있습니다. Pipenv 또는 Pipfile 인식 pip가 아직 표준 Python 도구가 아니며 Pipenv가 실제로 Pipfile에 대한 참조 구현임을 고려하면 문제를 해결할 수 있는 옵션이 거의 없습니다.

1) 프로젝트 문서에서 프로젝트가 Pipenv 에 의존한다고 지정하십시오. setup.py #$ 에서 Pipenv 에 계속 의존할 수 있으며 Python 환경에 Pipenv 가 설치되어 있지 않으면 중단됩니다. 구체적으로, 코드 기여자는 setup.py 로 프로젝트를 설치하기 위해 Pipenv 를 virtualenv 에 수동으로 설치해야 합니다.
2) Pipfile 에 따라 주기적으로 생성하는 requirements.txt 에 여전히 setup.py 가 의존합니다. 이것은 pip 및 setuptools 와 완전히 호환되지만 프로젝트를 빌드하고 배포할 때마다 유지 관리자가 requirements.txt 를 생성해야 합니다. 이것의 가능한 변형은 CI/CD 파이프라인이 빌드 시 requirements.txt 를 업데이트하는 것입니다.
3) Pipenv 버전을 프로젝트에 공급하고 setup.py from _vendor.pipenv.project import Project... 를 사용하여 호출합니다. 이것의 한 가지 변형은 전역 가져오기가 실패할 때 공급업체 버전에서만 가져오는 것입니다.
4) 여기에 제시되지 않고 내가 생각할 만큼 똑똑하지 않은 다른 옵션.

저는 개인적으로 (3)(https://github.com/kennethreitz/pipenv/issues/209#issuecomment-300550425 참조)을 사용하고 있습니다. Pipenv는 분명히 Pipfile을 기반으로 하는 virtualenv를 관리하기 위한 도구이고 반드시 Pipfile 라이브러리 자체가 아닐 수 있기 때문에 Pipenv 코드에 직접 의존합니다.

여기에서 읽은 내용을 바탕으로 이 문제가 해결되기를 바랍니다. 하지만 내가 잘못 말하거나 심각한 말을 한 경우 @nateprewitt로 알려주십시오.

나는 여기서 문제가 처음부터 requirements.txt 의 원래 오용(IMO)에서 발생했다고 생각합니다. pipenv 의 사용법과는 다릅니다.

나는 Donald Stufft의 setup.py vs requirements.txt의 멋진 기사를 가리킬 것입니다.
https://caremad.io/posts/2013/07/setup-vs-requirement/

TL;DR(하지만 정말 읽어야 하지만): setup.py 의 install_requires 는 패키지의 요구 사항(종속성)을 자세히 설명하기 위한 것입니다. requirements.txt (여기서는 Pipfile / Pipfile.lock 콤보로 대체됨)를 사용하여 필요한 것을 충족하는 데 사용할 정확한 패키지를 나열해야 합니다. 재현 가능한 환경을 만들기 위해 setup.py 에서 메타데이터를 가져옵니다.
requirements.txt install_requires 를 채우는 것은 뒤로 가는 것과 같습니다.

setup.py 의 install_requires =/= requirements.txt (또는 Pipfile / Pipfile.lock ).
Pipfile (또는 오히려 Pipfile.lock )는 앱 환경에 설치할 패키지의 단일 소스여야 합니다.
setup.py 의 install_requires 는 유효한 Pipfile.lock 를 생성하는 데 사용되는 메타데이터를 제공합니다.

마찰은 여기서부터라고 생각합니다. 나는 그것이 의미가 있기를 바랍니다.

나는 그 답장을 아주 좋아합니다, Vincent, 그리고 Pipfile.lock 가 requirements.txt #$ 에 대한 완전한(그리고 더 나은) 대체품이라는 것에 절대적으로 동의합니다.

그러나 지금 몇 개월 동안 Pipenv를 사용한 결과 Pipfile 를 사용하면 install_requires 가 Pipfile 에 있는 것과 거의 동일하다고 생각합니다. numpy 가 필요하면 pipenv install numpy 및 새 항목이 내 Pipfile의 [packages] 그룹에 들어갑니다. numpy = "*" . 즉, pip freeze > requirements.txt 를 사용하여 커밋하기 전에 생성했던 requirements.txt 와 사용법이 완전히 다릅니다.

아마도 이것은 내가 Pipenv를 사용하고 있는 독특한 방식일 뿐이며 그레인에 반대할 것입니다(또한 프로젝트 디렉토리 내부의 .venv/ 에 virtualenv를 설치하므로 저는 불량 Pythonista입니다). setup.py 와 Pipfile 사이에 벽이 있다는 Python 커뮤니티의 규칙을 쉽게 따를 수 있는 경우 | Pipfile.lock | requirements.txt .

@vphilippon, 내가 여기서 놓치고 있는 것은 무엇입니까?

@vphilippon 정보 감사합니다. 아마도 우리는 이것을 거꾸로 할 것입니다. 우리가 정말로 원하는 것은 반대인 것 같습니다. $의 -e . 와 관련하여 Donald가 언급한 것처럼 Pipfile에서 requirements.txt install_requires 의 추상 deps를 사용하는 방법입니다. requirements.txt . 이미 문제가 있었던 것 같은데(#339) 아무데도 가지 않는 것 같았습니다.

이것은 이미 Pipfile 구문에 포함되어 있습니까? 방금 요청 라이브러리 Pipfile 이 패키지 섹션에서 "e1839a8" = {path = ".", editable = true, extras=["socks"]} 를 사용한다는 것을 알았습니다. 비슷한 것이 Pipfile 예제 에서 분명하지만 다른 문서는 볼 수 없습니다.

첫째, 면책 조항: 제 전문 지식은 주로 lib 패키지에 관한 것입니다. 일부 포인트를 놓칠 수 있습니다. 나는 틀릴 권리를 보유하고 있으며 사용할 준비가 되어 있습니다!
또한 이것은 내 머리를 몇 번 긁게했습니다. 나는 이것에 대한 약간의 리뷰를 정말로 원합니다.

자, 이제 여기로 갑시다.

@elgertam 이라는 문장으로 시작하겠습니다.

[...] Pipfile을 사용하면 install_requires가 Pipfile에 있는 것과 거의 동일하다고 생각합니다. numpy가 필요한 경우 pipenv install numpy 및 새 항목이 내 Pipfile의 [패키지] 그룹 [...]에 들어갑니다.

numpy 를 환경에 추가했지만 앱의 종속성에 numpy 를 추가하지 않았습니다.
그것은 두 가지 다른 것입니다. 계속 읽으시면 제 말이 무슨 뜻인지 알게 되실 겁니다.

즉, pip freeze > requirements.txt를 사용하여 커밋하기 전에 생성했던 requirements.txt와 사용법이 완전히 다릅니다.

놀랍게도, 당신이 그것에 대해 생각한다면 당신의 사용법은 그렇게 다르지 않습니다:

• 이전 작업 흐름: pip install stuff -> pip freeze > requirements.txt -> requirements.txt install_requires 피드
• 새로운(시도한) 워크플로: pipenv install stuff -> Pipfile 자동 업데이트됨 -> Pipfile 로 install_requires 에 피드를 시도했습니다.
• 의도한 아이디어: install_requires -> pipenv install -> 환경 및 Pipfile.lock 에 항목 추가가 업데이트되었습니다.

그리고 의도한 방식으로 작동하려면 앱을 설치하고 싶다고 명시한 Pipfile 가 필요합니다.
@isobit에 의해 연결된 requests Pipfile 같은 것.

또는 예:

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

[dev-packages]
pytest = ">=2.8.0"
tox = "*"

[packages]
"-e ." = "*"

Pipfile 는 패키지의 종속성이 아니라 환경을 설명하는 것입니다. 보시다시피 위의 Pipfile 는 편집 가능한 모드의 로컬 패키지인 설치하려는 항목을 정의합니다.

이것은 지금은 모두 단일 패키지로 구동되기 때문에 약간 "쓸모없게" 보일 수 있지만 requests[security] 를 사용하여 앱을 설치하고 싶지만 앱에 대한 엄격한 종속성은 아닙니다. pipenv install requests[security] 하고 다음을 수행하십시오.

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

[dev-packages]
pytest = ">=2.8.0"
tox = "*"

[packages]
"-e ." = "*"
requests = { extras = ['security'] }

그리고 짜잔, 여기에 추상적 요구 사항과 구체적인 요구 사항 간의 차이점에 대한 예가 있습니다. gunicorn 또는 환경에 필요한 다른 것을 설치하려는 경우에도 마찬가지이지만 앱 자체의 일부는 아닙니다.

@vphilippon에서 내가 놓치고 있는 것이 무엇입니까? Pipfile의 [패키지]가 install_requires 또는 tests_require에서 사용하기에 너무 제한적인 이유는 무엇입니까?

내가 이것을 충분히 설명했다면, 당신은 그것이 반대 방향으로 되어 있음을 알 수 있습니다.
install_requires 에 종속성을 넣고 Pipfile 에 패키지를 넣은 다음 재현성을 위해 Pipfile.lock 와 함께 환경을 얻습니다. 패키지 종속성).

test_require 의 경우 이것이 이 모든 것에 맞는지 확신할 수 없음을 인정합니다. IIRC, setuptools 특정 기능입니다. 우리는 이것이 테스트를 위한 추상적인 종속성 집합이라고 주장할 수 있으며 pipenv 에서 해결하고 설치한 다음 모든 패키지에 대해 pipenv install --dev 를 수행할 것으로 예상할 수 있지만 저는 그것이 옳지 않다고 생각합니다. 이에 대한 명확한 생각이나 의견이 없으며 이에 대한 근거도 없습니다. 죄송합니다.

이 모든 것이 어떻게든 이해되기를 바랍니다.

@vphilippon 설명을 잘 해주셔서 납득이 갔던 것 같아요.

TL;DR: setup.py 에 추상적이고 절대적으로 필요한 종속성을 지정한 다음 Pipfile 및 Pipfile.lock 에 컨텍스트(따라서 구체성)를 추가합니다. 여기에는 환상적인 "-e ." = "*" 포함됩니다.

https://github.com/kennethreitz/pipenv/issues/209#issuecomment -337409290의 문제는 앱을 서버에 배포하려고 할 때 재현 가능한 환경을 얻지 못한다는 것입니다.

내 말은, 일반적으로 다른 프로젝트에서 사용될 _library_를 개발할 때 우리는 install_requires 가 상당히 느슨하기를 원합니다(=정확한 버전에 대한 바인딩 없음). 네. 그러나 웹 앱(또는 모든 앱)을 빌드하고 원격 서버 또는 도커 컨테이너에 배포할 때 고정된 종속성을 원할 것입니다. install_requires 에 정확한 버전을 지정하더라도 전이 종속성은 잠겨 있지 않으며 설치 시 전이 종속성의 다른(최신) 버전이 실제로 다운로드되어 배포가 중단될 수 있습니다.

(전이 종속성의 정확한 버전을 수동으로 선언하는 것은 옵션이 아닙니다. 너무 번거롭습니다.)

이 사용 사례에서 우리는 requirements.txt 스타일 잠금 파일(전이적 종속성에 대해서도 정확한 버전을 지정함)에 의존해야 합니다. 그러나 pipenv가 pipenv lock -r (예: pipenv lock --no-dev -r )에서 개발 요구 사항을 제외하도록 허용하는 것처럼 보이지 않으므로 실제로 이러한 requirements.txt 를 만들 수 있습니다. install_requires 로 읽습니까?

Donald Stufft의 기사를 인용하겠습니다.

응용 프로그램에는 일반적으로 테스트 대상이 되는 종속성 집합이 있으며, 종종 매우 복잡한 종속성 집합도 있습니다. 배포된 특정 인스턴스이기 때문에 일반적으로 이름이나 기타 패키징 관련 메타데이터가 없습니다. 이것은 pip 요구 사항 파일의 기능에 반영됩니다.

즉, 앱은 패키지가 아닙니다. 앱은 구체적인 종속성 세트가 설치된 환경입니다. 앱 종속성은 단일 패키지 install_requires 가 아니라 requirements.txt (또는 Pipfile / Pipfile.lock )로 표현되어야 합니다.

개인적으로, 고정된 종속성의 전체 세트(전환적 종속성 포함)는 패키지의 setup.py 가 아니라 앱에 대한 requirements.txt 에 있어야 합니다. 이것은 앱 배포가 pip install myapp==1.0.0 가 아니라 pip install -r requirements.txt (또는 pipenv install 가 있는 Pipfile.lock )라는 개념을 설명합니다. 여기서 requirements.txt 에는 myapp==1.0.0 는 물론 고정된 다른 모든 종속성 및 전이 종속성이 포함됩니다.
내가 좀 멀리 가는 것처럼 보일 수도 있지만 배포된 "앱"이 패키지 집합에 의해 구동되는 컨텍스트에서 작업했습니다. 앱 자체를 대표하는 단일 패키지가 없으므로 "패키지는 앱이 아니다"라는 개념이 꽤 일찍 내 얼굴에 던져졌습니다 😄 .

나는 Pipenv/Pipfile/Pipfile.lock이 이 아이디어를 따른다는 강한 느낌을 받았습니다.
그렇기 때문에 Pipfile.lock 에서 setup.py 의 install_requires 로 가는 간격이 있는 것 같습니다. 어떤 경우에도 실제로 그런 식으로 수행하려는 것은 아닙니다.

@maintainers 이 모든 것을 실제로 어떻게 보는지 알고 싶습니다. 나는 우리가 의존성을 어떻게 다루어야 하는지에 대한 비전을 설교해 왔지만 당신을 대신해서 말하고 싶지도 않습니다.

@vphilippon 다른 관점과 용어가 있다고 생각합니다. 그러나 궁극적으로 우리는 설치할 고정된 종속성 목록을 원합니다. 따라서 고정된 버전이 있는 requirements.txt (또는 이러한 선언된 종속성이 있는 패키지는 실제로 중요하지 않음). 문제는 실제로 그러한 파일을 만드는 방법입니다.

pip-compile ( of pip-tools )를 사용하면 requirements.in requirements.txt 를 컴파일할 수 있으며 여기에는 내 앱에 필요한 비개발 종속성만 포함됩니다. 귀하의 응답을 올바르게 해석하고 있는지 확실하지 않습니다. 고정된 종속성을 직접 유지해야 한다는 의미입니까($# requirements.txt setup.py 에 이미 있는 것과 약간 중복됨), 또한 전이 종속성? 해결책이 될 수 없습니다...

pipenv lock --no-dev -r 가 있으면 이 문제가 해결될 것입니다.

@tuukkamustonen 혼란을 드려 죄송합니다. 저는 실제로 install_requires 대 requirements.txt / Pipfile / Pipfile.lock 의 아이디어만 다루고 있었습니다.

따라서 고정된 버전이 있는 requirements.txt(또는 그러한 선언된 종속성이 있는 패키지는 실제로 중요하지 않음)입니다.

나는 구분이 정말 중요하다고 생각하지만, 당신이 말했듯이 여기에는 다른 관점이 있습니다. 지금은 동의하지 않는 것에 동의합시다. 참고로 특정 문제에 노이즈를 추가하지 않고 주제를 계속 진행할 수 있는 곳이 있으면 좋을 것입니다. IMO라는 커뮤니티에서 더 많은 토론과 공유가 필요한 유형입니다.

그러나 pipenv가 pipenv lock -r에서 개발 요구 사항을 제외하도록 허용하는 것 같지 않습니다.

그러나 궁극적으로 우리는 설치할 고정된 종속성 목록을 원합니다. [...] 문제는 실제로 그러한 파일을 만드는 방법입니다. [...] pip-compile(pip-tools)을 사용하면 requirements.in에서 그러한 requirements.txt를 컴파일할 수 있으며 내 앱에 필요한 비개발 종속성만 포함됩니다.

아, 처음에 그 부분을 건너뛰었습니다. 죄송합니다. 그리고 당신이 옳았던 것 같습니다. pipenv install --not-dev-stuff 라고 말하고 비개발 환경을 생성할 수 있는 방법을 찾을 수 없습니다. 그렇다면 2개의 별도 섹션을 갖는 요점은 무엇입니까? 나는 지금 뭔가를 놓치고있을 수 있으며 이는 setup.py 사용과 관련이 없습니다. 아마도 새로운 문제에서 논의할 가치가 있을 것입니다.

편집하다:
나는 여기서 실수를 했다. 나는 실제로 개발 패키지 없이 Pipfile.lock 를 생성하는 방법을 찾지 못했지만 , 새로운 환경에서 기존 Pipfile / Pipfile.lock , pipenv install dev 패키지를 설치하지 않습니다. 이것은 @tuukkamustonen 의 요점을 해결하지 못하지만 "프로덕트 환경"을 설치할 방법이 없다고 말한 것은 내 실수였습니다.

휴, 따라잡을 것이 많았습니다.

내가 크게 잘못 알고 있지 않는 한, #209(주석)의 코드는 휠(=이진 dist)을 빌드하는 경우 사용하기에 안전하지만 sdist(=소스 dist)를 빌드하는 경우에는 그렇지 않습니다.

@tuukkamustonen 이것은 배포용 독립 실행형 스크립트 에서만 사용하기 위한 것이며 setup.py에 포함하지 마십시오. 이것은 몇 달 전에 pipenv lock -r 가 있기 전의 반 해킹 해결 방법입니다. 이 접근 방식은 packages 및 dev-packages 를 분할하는 사용 사례에서 작동합니다.

Pipfile이 더 일반적인 표준이 될 때까지 개인적으로 (3)(#209(주석) 참조)을 사용하고 있습니다. Pipfile을 기반으로 하는 virtualenv를 관리하기 위한 도구이며, 반드시 Pipfile 라이브러리 자체일 필요는 없습니다.

@elgertam 이 댓글 이후로 당신의 의견이 흔들린 것 같지만, 프로젝트에 pipenv 를 묶는 것은 좋은 생각이 아닐 수도 있습니다. 명시적으로 금지하는 것은 없지만 이와 같이 사용할 때 문제를 일으키기 쉬운 경로 패치를 많이 수행합니다. 나는 이것을 "자신의 책임하에 사용"이라는 경고로 포장할 것입니다.

관리자 여러분의 의견을 듣고 싶습니다. 이것이 실제로 여러분이 이 모든 것을 어떻게 보고 있는지 알고 싶습니다. 나는 우리가 의존성을 어떻게 다루어야 하는지에 대한 비전을 설교해 왔지만 당신을 대신해서 말하고 싶지도 않습니다.

나는 당신이 프로젝트 기간 동안 우리의 비전과 매우 잘 일치한다고 생각합니다. @vphilippon을 잘 표현하여 이 모든 것을 컴파일해 주셔서 감사합니다!

이 토론의 다른 관련 부분이 #942로 옮겨진 것 같으므로 여기에서 우리가 좋다고 생각합니다. 내가 아무 것도 처리하지 않았다면 저에게 핑을 주세요.

저는 https://github.com/pypa/pipfile/issues/98 에서 구체적인 제안을 따랐습니다. 이 제안은 Python 라이브러리를 유지 관리하기 위해 DX를 개선할 수 있는 실행 가능하고 실용적인 무언가를 제공한다고 생각합니다.

생각?

import json, jmespath

install_requires = []
with open('Pipfile.lock') as f:
    context = json.loads(f.read())
    install_requires.extend(map(
        lambda n, v : n + v,
        jmespath.search('default | keys(@)', context),
        jmespath.search('default.*.version', context),
    ))

setup(
    name='foobar',
    packages=find_packages(),
    setup_requires=['jmespath'],
    install_requires=install_requires,
)

@cornfeedhobo 내 이해는 setup_requires가 pip와 잘 작동하지 않는다는 것입니다. 이 샘플을 사용하는 방법에 대해 좀 더 자세히 설명해 주시겠습니까?

setup.py는 일반 Python 코드로 평가되므로 jmespath를 먼저 설치하지 않으면 샘플이 작동하지 않습니다. setup_requires 인수는 실제로 아무 것도 달성하지 못합니다. 프로그램이 그 정도까지 도달하면 jmespath가 설치되는 것이 보장됩니다.

나는 이것을 다른 호에서 언급했지만 atm을 찾을 수 없습니다(이슈 트래커 전체에 중복된 토론이 너무 많아서 더 이상 아무것도 찾을 수 없습니다). 그래서 다시 말하겠습니다: 제발 구축되지 않은 것은 넣지 마세요- 적절한 대체를 제공하거나 완벽한 이유가 없는 한 내부 setup.py에 있습니다. 위의 setup.py 를 포함하는 패키지는 virtualenv에 jmespath가 설치된 Pipenv에서도 작동하지 않습니다. Pipenv는 깨끗한 환경에서 setup.py egg_info 를 호출하고 jmespath 가져오기를 실행하지 못합니다. 이것은 나쁜 습관입니다. 피해주세요.

@epot 나는 그것을 알지 못했다

@uranusjr 세부 사항과 함께 잘 생각한 답변에 감사드립니다. 저는 이 전체 문제를 조사하는 중이므로 더 당황스러워서 다시 돌아올 수 있습니다. pypa/pipfile#98도 추적 중입니다.

jmespath 가 필요하지 않다면?

import json


install_requires = []
tests_require = []

with open('Pipfile.lock') as fd:
    lock_data = json.load(fd)
    install_requires = [
        package_name + package_data['version']
        for package_name, package_data in lock_data['default'].items()
    ]
    tests_require = [
        package_name + package_data['version']
        for package_name, package_data in lock_data['develop'].items()
    ]

@mschwager 버전을 고정하고 싶지 않다면 사용자가 어려움을 겪을 것입니다. #1921은 == 를 사용하는 라이브러리의 예이며 결국 사용자의 빌드를 깨뜨립니다.

죄송하지만 패키지로 사용하기 위해 setup.py 를 사용하거나 해당 패키지의 종속성을 관리하기 위해 requirements.txt / Pipfile 를 사용하는 것의 차이점은 무엇입니까? 필요한 라이브러리는 setup.py 와 requirements.txt / Pipfile 사이에서 동일 해야 합니다. 맞습니까? 따라서 Pipfile 를 통합하지 않을 이유가 없습니다. setup.py 는 이미 requirements.txt 를 구문 분석합니다. Pipfile 를 구문 분석할 수 없는 이유는 무엇입니까?

requirements.txt 를 없애고 Pipfile 만 사용하는 것이 좋습니다.

아니요, 동일해야 _가지는_ 이유가 없습니다. 그것은 상당히 급진적인 가정이며 커뮤니티의 많은 사람들이 다른 의견을 요구할 것입니다.

그러나 실제로 그것들이 _할 수 있는_ 이유가 있습니다. Pipenv는 그것을 배제하지 않습니다. 범위 밖이며 이 프로젝트에서 지원하지 않습니다. 이를 지원하는 라이브러리를 완전히 빌드하고 pip 10.0에 implrmrnet된 PEP 518 을 활용하여 빌드 시간 지원을 제공할 수 있습니다.

당신이 말했듯이 setup.py가 Pipfile을 구문 분석하는 것을 허용하지 않을 이유가 없습니다. 나는 당신이 그것을 실현하기를 기대합니다 :)

setup.py의 추상 라이브러리를 좋아하는 사람도 있지만 꼭 필요한 것은 아니라는 것을 이해하시겠습니까? 내 말은 golang은 구체적인 요구 사항만 가지고 있지만 이름과 일치하기 때문에 필요한 lib를 자신의 포크로 대체할 수 있다는 것을 의미합니까? setup.py 통합이 범위에 포함되지 않는다는 것을 이해할 수 있습니다.

그러나 pipenv의 장기 로드맵이 무엇인지 보는 것이 흥미로울 것입니다. 파이썬에서 도구가 되는 것을 보는 것이 좋을 것입니다. 예를 들어 어떤 식으로든 setup.py를 대체하거나 사용자에게 적절한 setup.py를 생성합니다. 어느 쪽이든 pipenv가 사실상 패키지 관리자가 되는 것은 굉장합니다. setup.py를 포함하도록 범위를 확장할 가능성이 있는지 궁금하십니까?

pipenv가 npm 등과 같은 경우 해당 package.json은 원격 설치를 허용합니다. pipenv가 setup.py와 상호 작용하거나 교체할 수 없어 범위 내로 만들 수 없습니다. 말이 되는 건가요 아니면 미친 약을 먹는 것처럼 들립니까?

필수품이라고 생각해주시면 감사하겠습니다. 그것이 매우 중요하다고 생각하신다면, 저는 우리가 Pipfile 기반 빌드 시스템을 즉시 실행할 수 있을 것이라고 믿습니다.