Readthedocs.org: 핍파일 지원

@Stibbons님 감사합니다. 물론 이에 대한 PR을 제출하고 싶다면 기여를 언제나 환영합니다.

나는 pipenv에 대한 지원으로 게임을 시작했는데 pip install에 대한 호출을 대체할 수 있을 것 같습니다. readthedocs.yml 파일을 통해 옵션을 제공하고 싶을 것이므로 다음이 필요합니다.

• [ ] doc_builder/python_environments.py 에서 pipenv에 대한 조건부 호출
• [ ] readthedocs-build 리포지토리에서 readthedocs.yml 지원
• [ ] 이 리포지토리에서 readthedocs.yml 지원

예, 그것은 pip(실제로는 래퍼)의 직접적인 대체이며 pipenv install thispackage 하고 virtualenv에 패키지를 설치하고(pew 사용) 그에 따라 Pipfile을 수정합니다. ReadTheDocs의 경우 pipenv install --dev 하고 lib가 환경에 설치되었는지 확인하는 것이 좋습니다. 나는 보통 -e . 를 사용하여 개발 중인 내 라이브러리를 virtualenv에 주입하지만 모든 사람이 그렇게 하는지 확실하지 않습니다.

실제로 pipenv install --dev --ignore-pipfile 합니다. --ignore-pipfile 없으면 pipenv 는 Pipfile 의 패키지를 업그레이드하려고 할 뿐 실제로는 결정적 빌드를 수행하지 않습니다. https://github.com/kennethreitz/pipenv/issues/954#issuecomment -338777638을 참조

참으로

나는 이미 다른 프로젝트에 pipenv를 사용하고 있으므로 어느 정도 익숙합니다. 나는 우리의 경우 실제로 기존 virtualenvs를 활용하기 위해 --system 도 원한다고 믿습니다. 이를 위한 특별한 저장소가 있으므로 venv가 빌드 간에 유지됩니다.

@tuukkamustonen 이것은 약간 혼란

가장 정확한 것은 pipfile.lock을 확인하는 것입니다. 그렇다면 --ignore-pipfile , 그렇지 않으면 하지 않습니까?

이러한 옵션 중 일부는 readthedocs.yml을 통해 추가/허용된 재정의가 될 수 있으며 --dev 는 그 중 하나입니다.

의 경우 a는 requirements.txt , 우리는 그냥 사용할 수 있어야합니다 pipenv install 대신 pip install

양쪽 다 괜찮습니다. requirements.txt를 고정하면(예: pip-tools 사용) 잠금 파일을 사용할 때처럼 작동합니다.
범위 또는 버전 없이 버전만 설명하면 Pipfile처럼 작동합니다.
잠금 파일은 시스템에 따라 다르며 마커(예: « python_version < 3 »)가 없지만 둘 다 작동해야 합니다.
나는 'pipenv install —dev —system'을 사용할 것입니다. 그것은 'pip install -r requirements.txt -r requirements-dev.txt'와 같습니다.

@agjohnson 저도 pipenv install 실행하면 Pipfile.lock 따르지 않고 대신 Pipfile 를 살펴보고 이해합니다. 정확한 버전으로 고정하지 않은 모든 패키지를 업그레이드한 다음 _update_ Pipfile.lock . 따라서 pip-compile 및 pip-sync (pip-tools 패키지에서)가 결합된 것과 같습니다. 조금 혼란스럽다고 생각합니다.

가장 정확한 것은 pipfile.lock을 확인하는 것입니다. 그렇다면 --ignore-pipfile, 그렇지 않으면 하지 않습니까?

예, 결정적 빌드를 따르는 경우 잠금 파일을 따라야 하고 --ignore-pipfile 주어져야 합니다. 그렇지 않으면 어떻게 의미가 있을지 모르겠습니다. 그리고 pipenv update pip-sync 와 같은 패키지를 제거/설치하지만 --ignore-pipfile 옵션이 없습니다... 흠.

잠금 파일은 시스템에 따라 다르며 마커(예: « python_version < 3 »)가 없지만 둘 다 작동해야 합니다.

이것은 좋은 알림입니다. pip-tools 또는 pipenv(아래에서 pip-tools 사용)는 "범용" 잠금 파일을 지원하지 않습니다. 따라서 Windows의 python 3.6에서 잠금 파일을 만든 다음 Linux의 3.4에서 실행하면 잠금 파일이 3.6/Windows 환경을 예상하기 때문에 문제가 발생할 수 있습니다. https://github.com/kennethreitz/pipenv/issues/857 및 https://github.com/jazzband/pip-tools/issues/563을 참조하세요.

pipfile.lock을 체크인하지 않는 프로젝트에서 pipfile을 무시한다는 것은 무엇을 의미합니까?

이러한 프로젝트는 결정적 빌드를 얻지 못합니다. 괜찮지만 문서화해야 합니다. pipenv의 주요 이점 중 하나는 결정론적 빌드를 얻는 것입니다(단순한 requirements.txt 보다 개선). 그러나 말했듯이 요구 사항은 아닙니다. 사용자는 그것을 인정해야 합니다.

requirements.txt의 경우 pip install 대신 pipenv install을 사용할 수 있어야 합니다.

pipenv requirements.txt 스타일 파일을 읽지 않는다고 생각합니다. Pipfile 가 없는 경우 이전 행동에 의존하지 않는 이유는 무엇입니까?

이것은 좋은 알림입니다. pip-tools 또는 pipenv(아래에서 pip-tools 사용)는 "범용" 잠금 파일을 지원하지 않습니다. 따라서 Windows의 python 3.6에서 잠금 파일을 만든 다음 Linux의 3.4에서 실행하면 잠금 파일이 3.6/Windows 환경을 예상하기 때문에 문제가 발생할 수 있습니다. kennethreitz/pipenv#857 및 jazzband/pip-tools#563을 참조하십시오.

아 예, Pipfile을 무시하고 Pipfile.lock에 의존하는 것이 옵션이어야 하지만 기본적으로 꺼져 있습니다. 범용 잠금 파일이 없으면 환경이 빌드 이미지와 동일한 OS 또는 Python 버전이라고 보장할 수 없습니다.

pipenv가 requirements.txt 스타일 파일을 읽지 않는다고 생각합니다. Pipfile이 없는 경우 이전 동작에 의존하지 않는 이유는 무엇입니까?

Pipfile이 없고 requirements.txt가 사용 가능한 경우 pipenv install 가 자동으로 이를 Pipfile로 변환합니다. 마찬가지로 파일 이름이 foo.txt 경우 pipenv install -r foo.txt 는 임의로 명명된 파일을 선택합니다. RTD에서 지원해야 하는 두 가지 모드입니다.

요구 사항.txt에서 변경되지 않으며, 프로그래머의 작업에 따라 재현할 수도 있고 그렇지 않을 수도 있습니다. 귀찮게 하지 않고 --dev 를 사용하면 대부분 ReadTheDoc이 트리거되기 때문입니다. 동시에 트래비스보다.

나중에 범용 잠금 파일이 해결되면 이것은 Rtd에 적용할 수 있지만 이것은 트래비스 빌드에서보다 "중요하지" 않습니다(아티팩트가 실제 휠이 아니라 문서이기 때문에). 그리고 우리는 이 기능을 가지고 있지 않습니다. 트래비스.

또는 더 간단하게 개발자가 설치 라인( pip install -r requirements.txt 또는 pipenv install --dev )을 작성하도록 하면 더 다양한 솔루션입니다.

이 문제의 상태는 무엇입니까? 제가 도와드릴 수 있는 일이 있을까요?
감사 해요!

얘들 아.
소식이 있나요?

업데이트가 없습니다. 원한다면 이 작업을 자유롭게 수행하십시오.

안녕하세요 여러분, 먼저 이 프로젝트에서 여러분이 하는 모든 일에 감사드립니다 :smiley:

저는 이 문제에 관심을 가지고 있으며 사람들이 이 기능을 어떻게 사용할 것으로 예상하고 어떤 사용 사례를 수용해야 하는지에 대해 몇 가지만 기록하고 싶습니다. 사람들은 종종 pipenv를 어떻게 사용해야 하는지 혼란스러워 하기 때문에 이 기능으로 모두를 만족시키기는 어려울 것으로 예상합니다.

나는 pipenv 문서의 이 섹션에 제공된 정보를 주요 참조 지점으로 사용할 것입니다. 거기에 나열된 사용 사례와 지침을 수용하면 대부분의 개발자가 만족할 것입니다.

RTD의 설치 과정

따라서 현재 virtualenv가 생성된 후 설치 프로세스에는 세 단계가 있습니다.

1. RTD의 핵심 요구 사항 설치
2. pip를 사용하여 requirements.txt 파일에서 사용자 요구 사항 설치(선택적 단계)
3. pip install . 또는 python setup.py install --force 패키지 자체 설치(선택 사항)

pipenv가 이러한 단계에 적합한 방법

pipenv 자체의 설치는 첫 번째 단계에서 수행해야 합니다. YAML 구성을 기반으로 조건부여야 한다고 생각합니다.

이제 pipenv의 일부(또는 아마도 "대부분의") 사용법은 실제로 2단계와 3단계를 결합합니다. 많은 프로젝트가 Pipfile에 -e . 또는 이에 상응하는 사양을 갖고 있기 때문입니다. 패키지의 하위 종속성을 포함합니다).

그러나 위에 링크된 문서에 지정된 것처럼 Pipfiles는 프로젝트의 install_requires 의존 하지 않고 자체적으로 종속성을 관리할 수도 있습니다. 이 경우 pipenv를 사용하여 2단계를 완료하고 필요한 경우 3단계에 pip install . 또는 python setup.py install 를 사용합니다.

내가 생각할 수 있는 가장 간단하고 유연한 접근 방식은 pipenv install {opts} 를 2와 3 사이의 추가 단계로 수행하는 것입니다. 2단계와 3단계는 이미 선택 사항이므로 사용자에게 원하는 방식에 대해 많은 자유를 줍니다. 상호 배타적인 구성 옵션으로 사용자를 혼동하지 않고 환경을 설정합니다. 설명서는 이러한 다양한 구성 옵션을 함께 사용할 수 있는 방법에 대해 분명히 명확해야 합니다.

pipenv install 인수

사용자에게 자유를 주고 새로운 pipenv install 플래그에 대한 구성을 미래에도 보장하기 위해 사용자가 YAML에서 문자열로 사용하려는 플래그를 지정할 수 있도록 허용해야 한다고 생각합니다. 그러나 pipenv가 다른 virtualenv를 생성하지 않도록 --system 영구 플래그로 설정해야 합니다. 사용 pipenv 가상 환경을 관리하는 것은 우리가 이미 가상 환경 설정을위한 사랑스러운 견고한 설계 및 API 가지고 불필요 virtualenv , 그리고 pipenv 의 가상 환경 관리가 더 최종 사용자 QoL 기능.

기본 동작이 Pipfile.lock 에서 설치하는 것이기 때문에 --ignore-pipfile 는 불필요하다고 생각합니다.

그러나 어떤 경우에도 패키지 또는 요구 사항 파일을 pipenv install 대한 인수로 지정해서는 안 된다고 생각합니다. 이는 Pipfile에 종속성을 추가하고 개발 환경을 결정적으로 다시 생성하지 않는 데 사용되기 때문입니다.

구성 레이아웃

따라서 위의 요점을 감안할 때 내 접근 방식은 YAML에 다음 옵션을 추가하는 것입니다.

pipenv_install: True|False
pipenv_install_opts: OPTIONS

편집: 두 번째로 이러한 옵션을 pipenv 키 아래의 하위 키로 사용하는 것이 바람직할 것입니다.

python 키에 포함하지 않는 이유는 가장 유사한 requirements_file 키와 같은 수준에 있어야 한다고 생각하기 때문입니다.

pipenv를 사용한 설치 요약

1. pipenv_install 가 True인 경우 pipenv를 포함하여 pip로 RTD의 핵심 요구 사항을 설치합니다.
2. 선택적으로 pip를 사용하여 requirements.txt 파일에서 요구 사항을 설치합니다.
3. 선택적으로 pipenv install --system {opts}
4. 선택적으로 pip install .[extras] 또는 python setup.py install --force 중 하나를 수행하거나 둘 다 수행하지 않습니다.

다른 관점이 있거나 개선할 수 있는 사항이 있으면 알려주세요. 스마일리:

@Tobotimus 감사합니다. https://github.com/orgs/rtfd/projects/2 의 v2를 수행 중이며 이것이 있어야 한다고 생각합니다.

@stsewd 아 YAML 파일 완료 이정표를 찾았습니다. 여기 새롭기 때문에 여전히 다소 비틀거리고 있습니다.

이전 구성에 대한 패치로 #4254를 열었지만 새로운 사양에 따라 리팩토링하게 되어 기쁩니다. 새 구성에 대한 일종의 기능 분기가 있습니까? 감사 해요!

rtd-build repo를 readthedocs.org repo https://github.com/rtfd/readthedocs.org/pull/4242로 옮기고 있습니다. 여기에 몇 가지 아이디어가 있습니다. https://docs.readthedocs.io/en/latest /design/yaml-file.html 이며 이것은 v2 https://github.com/rtfd/readthedocs.org/blob/master/readthedocs/rtd_tests/fixtures/spec/v2/schema에 대한 기본 스키마의 일종입니다.

감사합니다. #4254의 접근 방식은 python 키 아래에 pipenv 섹션을 배치하기 rtd-build repo용으로 준비한 패치 입니다. pipenv PR을 계속하기 전에 #4242가 병합되고 V2 구성 파서에서 더 많은 진행이 이루어지기를 기다릴 것이라고 가정합니다.

포팅 프로세스를 완료하려면 더 많은 작업이 있으므로 해당 프로세스가 먼저 완료될 때까지 기다리는 것이 가장 좋습니다. 지금은 readthedocs_build가 동결된 것으로 간주할 수 있습니다.

포팅되면 PR을 다시 작업하여 여기에 보관할 수 있습니다.

현재로서는 v2 스키마 사양 파일을 업데이트하는 별도의 PR이 시작하는 가장 좋은 방법입니다. 여기에서 테스트와 스키마를 찾을 수 있습니다.
https://github.com/rtfd/readthedocs.org/blob/master/readthedocs/rtd_tests/fixtures/spec/v2/schema.yml
https://github.com/rtfd/readthedocs.org/blob/master/readthedocs/rtd_tests/tests/test_build_config.py

이것은 스키마 변경에 대한 변경 및 근거를 설명하는 가장 좋은 위치입니다.

즉각적인 피드백은 pipenv.options 노출을 좋아하지 않는다는 것입니다. 다른 도구에서는 이 작업을 수행하지 않고 특정 옵션을 지원합니다. 나는이 모든 미만이어야 동의 python.pipenv 키, 그러나 아마 우리는 또한 변경해야 python.install 지원하기 위해 pipen 대신 pip .

편집: cc @Tobotimus , 또한 기여에 대해 🎉! 큰 프로젝트의 중간에 PR 착륙 죄송합니다

@agjohnson 정보 감사합니다! 그리고 피드백도 감사합니다. pipenv.options 노출이 나머지 스키마와 일치하지 않는다는 것을 이해할 수 있습니다.

이 경우 지금 지원해야 하는 특정 옵션은 --dev (개발 종속성 설치)일 것입니다. 다른 옵션:

• --skip-lock 는 의존성을 모호하게 만들고 도구의 목적을 무력화하기 때문에 사람들이 사용하는 것이 나에게 의미가 없습니다.
• --ignore-pipfile 우리가 지속적으로 추가 할 수 있습니다, 그것은 차이를 이후 시간의 99 %하지 것이다 pipenv install 항상에서 설치 자체 Pipfile.lock 가와 유효 기간이 아니라면 Pipfile .
• --system 는 새로운 가상 환경을 생성하지 않도록 지속적으로 유지되어야 합니다.

또한 상당한 경우 pipenv 가 실제로 pip 를 대체하는 것이 아니라 python.requirements 대한 대체가 python.install 를 변경할 필요가 없다고 생각합니다. 어떤 사용자는 pipenv install 단계와 pip install . 단계를 모두 원할 것입니다.

좋아요, 동의합니다. --dev 가 현재 지원해야 하는 주요 기능인 것 같습니다.

이 작업을 시작할 때 pipenv 를 pip 대체품으로 취급할 수 있다고 생각했습니다. pip 및 pipenv 단계가 모두 있는 워크플로를 사용하는 패키지의 예가 있습니까? 과연 어떤 모습일지 궁금하기만 합니다.

pip 단계를 대체하는 것과 반대로 pipenv 단계를 추가하는 것은 잘못된 것이 아닙니다. conda에 대해 많이 알지 못하더라도 아마도 그것이 우리가 conda를 취급하는 방식이기도 합니다.

솔직히 말해서 해당 워크플로를 사용하는 패키지의 예가 없습니다. pipenv 설명서의 이 섹션에서 내 예제 사용 사례를 기반으로 내 자신의 사용에 최대한 편향되지 않도록 했습니다(즉, pipenv 는 Pipfile.lock에서 프로젝트 자체를 설치하므로 pip 대체합니다. 특히 이 워크플로는 다음과 같습니다.

애플리케이션의 경우 _Pipfile_에서 종속성과 이를 가져올 위치를 정의하고 이 파일을 사용하여 Pipfile.lock 의 구체적인 종속성 세트를 업데이트합니다. 이 파일은 프로젝트에서 작동하는 것으로 알려진 특정 멱등성 환경을 정의합니다. Pipfile.lock 는 진실의 근원입니다. Pipfile 는 사용할 종속성의 정확한 버전에 대해 여전히 모호한 상태를 유지할 수 있다는 점에서 잠금 파일을 생성하는 데 편리합니다.

해당 워크플로에서는 pipenv 를 사용하여 패키지 자체를 설치하는 것에 대해 언급하지 않습니다.

그러나 조금 더 조사한 후에는 이 워크플로가 실제로 pip 설치가 불가능한 프로젝트에 더 집중될 수 있습니다. pipenv 와 poetry 를 비교할 때 Python Packaging User Guide 를 인용하려면 다음을 수행하십시오.

pipenv 는 PyPI의 구성 요소에 의존하는 작업 중인 애플리케이션 자체가 pip -설치 가능한 Python 패키지로 배포를 지원한다는 가정을 명시적으로 피합니다.

따라서 pipenv 를 pip 대한 대체품으로 취급하는 것으로 충분하다고 생각하는 것이 맞을 것입니다.

안녕하세요 @agjohnson입니다. 나는 주로 pipenv를 사용하는 모든 내 파이썬 응용 프로그램 (그리고 내 librairies PBR에 매우 감사 등을). 지금까지는 매우 만족하며 현재 Pipfile을 지원하지 않더라도 readthedoc이 만족할 수 있도록 requirements.txt를 생성하는 작은 패키지 를 개발했습니다.

readthedocs compatible, pipenv 등 새 프로젝트에 대한 모든 것을 부트스트랩 하는

따라서 ReadTheDocs가 Pipfile(및 pipenv)을 원활하게 지원한다면 이 문제를 없앨 수 있다면 매우 기쁠 것입니다.

TD; DR: pipenv는 주로 라이브러리가 아닌 응용 프로그램을 위한 것입니다. 그러나 pipenv를 사용하는 앱에 대한 readthedocs는 훌륭할 것입니다!

물론 "--dev"를 사용해야 하며 기본적으로 사용해야 한다고 생각합니다. 잠금 파일에 대한 질문은 까다 롭습니다. 그것에 대한 명확한 의견이 없습니다. 나는 그것을 사용자가 선택 가능하게 할 것입니다.

• 잠금 파일을 사용하여 빌드를 재현할 수 있는지 확인합니다. 이는 라이브러리와 애플리케이션 모두에 대한 요구 사항이어야 합니다.
• 그러나 라이브러리의 경우 패키지의 종속성을 잠그면 안 되므로 pip가 pip install mydeps 에 대한 종속성 버전을 해결하도록 합니다.

현재 내 솔루션은 라이브러리에 대한 잠금 파일을 추적하지 않는 것이지만 빌드를 재현할 수 없게 만듭니다. 나는 행복하지 않지만 그것으로 살 수 있습니다.

현재 프로젝트에서 Pipfile을 감지, 그냥 모든 앞에 추가 pip install 와 pipenv run : 예를 들어 같은 pipenv run pip install sphinx sphinx-rtd-theme . pipenv install 를 사용하지 마십시오. 리졸버를 시작하므로 무의미하고 위험합니다.

이에 대한 업데이트가 있습니까? 레이더에 높은 위치에 있어야 할 것 같습니까? 코드베이스를 해킹하고 업데이트를 받을 수 없기 때문에 readthedocs를 사용하는 것을 정말로 막고 있습니다.

@petersmithca 이것은 우리의 레이더에 있습니다. 먼저 구성 파일의 v2를 마무리하고 pipfile을 사용하여 프로젝트의 워크플로를 더 잘 이해하려고 노력하고 있습니다. 원하는 워크플로에 대한 모든 도움말/코멘트를 환영합니다.

아마도 오해일 수 있지만 본질적으로 내 워크플로는 기본적으로 virtualenv 및 pip install -r requirements.txt 을 pipenv install 대체하고 환경의 모든 활성화를 pipenv shell 대체합니다

@petersmithca pipenv install pipenv sync --dev 대신 sync 는 설치된 패키지가 Pipfile.lock 정의된 패키지와 일치하는지 확인하지만 해당 파일이 존재하지 않는 경우 pipenv install --dev 이 의미가 있습니다.

전에는 sync를 사용하지 않았지만 --dev에 동의합니다.
내 개발자 아래에 있는 문서, 방금 잊어버렸습니다.

2018년 8월 29일 수요일 오후 1:59 Miguel Sánchez de León Peque <
[email protected]>은 다음과 같이 썼습니다.

@petersmithca https://github.com/petersmithca pipenv 설치 대신
대신 pipenv sync --dev를 사용합니다. 나는 일반적으로 종속성을 넣습니다.
의 "dev" 섹션에 있는 문서 생성 및 테스트와 관련된
핍파일. 또한 동기화는 설치된 패키지가 패키지와 일치하는지 확인합니다.
Pipfile.lock에 정의되어 있지만 해당 파일이 없으면 pipenv
install --dev는 의미가 있습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rtfd/readthedocs.org/issues/3181#issuecomment-417027482 ,
또는 스레드를 음소거
https://github.com/notifications/unsubscribe-auth/AE1F_bRgPmEc1uydCZKtJtT95vwIua_Eks5uVshbgaJpZM4QDCg9
.

잠금 파일을 강제로 사용하려면 pipenv install --ignore-pipfile --dev 를 선호합니다.

venv/virtualenv 대신 pipenv를 사용하는 것에 대해 실제로는 여전히 사용할 수 있습니다.

pipenv 문서에서

기본적으로 Pipenv는 가상 환경 내에서 실행되는지 여부를 감지하고 가능한 경우 재사용합니다. 이것은 일반적으로 원하는 동작이며 사용자가 Pipenv와 함께 사용자 구축 환경을 사용할 수 있도록 합니다.

따라서 pipenv를 다른 설치 방법(예: pip 또는 setup.py)으로 취급할 수 있습니다.

지금 pipenv를 테스트하고 있는데 다음을 찾았습니다.

• --ignore-pipfile 는 잠금 파일이 없으면 생성하려고 시도합니다.
• pipenv install 실행하면 잠금 파일이 생성됩니다.
• --skip-lock 실행하면 잠금을 생성하지 않고 pipfile에서 설치됩니다.

잠금 파일 생성 시 오류가 발생하면 종속성을 설치하지 않습니다(호환되지 않는 종속성이 있는 경우 실패할 수 있음).

그래서 un-pined dep(라이브러리와 같은)를 사용하는 사람들은 이 문제가 있을 수 있습니다. 사용자가 해결해야 하는 문제입니까? 아니면 두 가지 옵션을 모두 넣어야 합니까? --ignore-pipfile 및 --skip-lock ? ( --ignore-pipfile 는 기본적으로 켜져 있습니다)

Pipenv는 사용자 지정 Pipfile 지정을 지원하지 않습니다(roo 디렉토리 이외의 설치를 지원할 계획입니다). 그래서 환경 변수로 넣을 계획입니다. 명령은 다음과 같습니다.

 PIPENV_PIPFILE=./custom/path/Pipfile pipenv install --system --dev --ignore-pipfile --skip-lock 

--skip-lock 및 --ignore-pipfile 는 yaml 파일의 옵션이고 --ignore-pipfile 는 기본적으로 켜져 있습니다. 또한 --dev 는 옵션이며 기본적으로 꺼져 있습니다.

이를 통해 동일한 가상 환경에 종속성을 설치합니다. 이 프로젝트 https://github.com/gsemet/cfgtree에 대해 다음과 같은 구성을 사용하고 있습니다.

version: 2
sphinx:
  configuration: docs/conf.py
python:
  install:
    - pipfile: .
      skip_lock: true
      dev: true
    - path: .
      method: pip

안녕하세요 여러분, 저는 rtd에서 pipfile 지원을 테스트하고 있습니다. pipfile을 사용하는 프로젝트(그리고 빌드할 문서가 있음)에 대해 의견을 말씀해 주시겠습니까? 그것은 테스트에 많은 도움이 될 것이며 버그가 적은 구현 p를 가져올 것입니다.

https://github.com/dls-controls/pytac 은 Pipenv를 사용하고 pipfile이 있지만 정확한 목적을 위한 rtd-requirements.txt 파일도 있습니다. https://pytac.readthedocs.io/en/latest/에 있습니다.

봐주셔서 감사합니다!

이것이 pipenv-to-requirements/ 의 역할입니다. :)

@willrogers 현재 구현으로 문서를 작성할 수 있었습니다. 감사합니다!

이 문제는 최근 활동이 없었기 때문에 자동으로 오래된 것으로 표시되었습니다. 더 이상 활동이 없으면 폐쇄됩니다. 귀하의 기여에 감사드립니다.

@stsewd 이 문제에 대한 업데이트가 있습니까? :붉히다:

봇에게 죄송합니다. 이것은 오래되지 않았습니다. 우리는 https://github.com/rtfd/readthedocs.org/pull/4740에 의해서만 차단되며, 다른 검토가 필요합니다. 그런 다음 그 위에 https://github.com/rtfd/readthedocs.org/pull/4783 을 병합할 수 있습니다. 이 기능을 구현하는 데 거의 근접했습니다.

안녕하세요 여러분, 이것에 대한 업데이트가 있습니까? #4740이 병합된 것 같은데 #4783도 병합될 수 있나요? 이 기능이 정말 기대됩니다.

이것은 아직 계획에 있습니까? 내 작업은 pipenv를 독점적으로 사용합니다. 그리고 그것의 지원 없이, 나는 일을 작동시키기 위해 약간의 해킹을 구축해야 합니다

@stsewd 이전에 pipenv에서 실행되는 프로젝트에 대해 주석을 달아야 한다고 언급했습니다. https://github.com/pyvec/docs.pyvec.org 및 https://github.com/honzajavorek/cojeapi를 유지 관리

둘 다 현재 문서 개발자가 종속성을 망칠 때마다 pipenv lock --requirements > requirements.txt 를 실행해야 합니다. 이 파일이 동기화되지 않았는지 확인하는 CI가 있지만 작업하는 것은 성가신 일입니다. 현재로서는 더 나은 해결 방법이 있는지 확실하지 않습니다. 누군가가 더 원활한 작업 흐름으로 이어질 제안을 해준다면 기쁠 것입니다.

(사람이 린터에 관심이 있다면, 볼 이 스크립트를 . 작품 올바르게로 dependabot .)

안녕하세요 여러분, 여기에서 침묵에 대해 죄송합니다. 우리는 pipenv를 지원하는지 여부를 결정하려고 합니다.

• 한 가지는 pipenv가 PEP 517 https://github.com/pypa/pipenv/issues/2787#issuecomment -416685889를 채택하지 않는다는 것입니다. pip를 사용하고 구성 파일에서 더 많은 옵션을 구현하지 마십시오).
• pipenv의 마지막 릴리스는 1년 전 https://pypi.org/project/pipenv/#history 이며 프로젝트가 어떤 방향으로 나아갈지 확실하지 않습니다.
• Pipenv는 deps를 해결할 때 느리고 이미 conda에 동일한 문제가 있습니다. 그러나 conda는 최근에 개선되었으므로 pipenv는 시간이 지남에 따라 해당 영역에서도 개선될 수 있습니다.
• 우리는 실험적인 방식으로 pipenv를 지원하려고 시도할 수 있으므로(우리는 이미 pipenv 지원과 함께 PR 종류가 준비되어 있음) 보증 없이 제거/변경할 수 있습니다.

이러한 결정의 일부는 우리가 pipenv를 구현하는 경우 영원히 유지해야 하는 것입니다. 여러분의 의견을 알려주세요.

나는 개인적으로 Pipenv 사용을 중단했습니다(여전히 Conda와 Poetry 사용). PEP 517로 가는 것이 최선의 선택이 될 수 있다고 생각합니다.

Pipenv는 여전히 최고의 지원 옵션입니다. pycharm 및 spacemacs와 같은 편집기는 pipenv를 지원합니다. Dependabot은 pipenv를 지원합니다. pipenv를 지원하지 않는 유일한 도구는 readthedocs입니다.

나는 미래에 무슨 일이 일어날 지 전혀 모른다. pipenv가 1년 넘게 업데이트되지 않았다는 사실은 pipenv에 좋지 않습니다. 나는 시[1]와 플리트[2]가 활발하게 유지되는 것을 본다. 핍 자체가 개선 될 수 있습니다.

하지만 지금은 좋든 싫든 pipenv가 최선의 선택이라고 생각하고, 나중에 교체하더라도 오래도록 레거시 프로젝트에서 사용될 것 같습니다.

개인적으로 Python 커뮤니티가 requirements.txt 기반 pip 설치의 문제를 해결하기 위해 선호하는 솔루션을 빨리 선택할수록 더 좋습니다. 그렇지 않으면 모든 것이 프로젝트에 대해 다른 솔루션을 선택하므로 readthedocs와 같은 도구는 모두 다양한 솔루션을 지원해야 할 수 있습니다.

노트:

[1] 최근에 시를 시도했는데 기존 requirements.txt 기반 시스템에서 마이그레이션하는 좋은 방법이 없다는 것을 알았습니다. 그러나 시가 미래의 방식이라면 이 문제는 쉽게 고칠 수 있습니다. 시+종속성은 특별히 가볍지 않습니다. 이는 CI 실행을 위해 즉석에서 설치할 때 중요합니다.

[2] flt에 익숙하지 않습니다. 한 번 봐야 할 것 같습니다.

그렇다면 시를 지원할 계획은 없나요? 현재는 사용할 수 없습니다
내가 로컬에서 repo를 해킹하지 않는 한 Pipenv 또는 Poetry가 있는 제품
물론 업데이트할 때마다 덮어씁니다.

2019년 11월 26일 화요일 오후 2:04 Santos Gallegos [email protected]
썼다:

안녕하세요 여러분, 여기에서 침묵에 대해 죄송합니다. 여부를 결정하려고 합니다.
pipenv 지원 여부.

• 한 가지는 pipenv가 PEP 517 pypa/pipenv#2787을 채택하지 않거나 채택하지 않는다는 것입니다.
  (논평)
  https://github.com/pypa/pipenv/issues/2787#issuecomment-416685889
  시나 플리트와 같은 다른 도구와 마찬가지로(이를 통해 pip를 호출할 수 있습니다.
  구성 파일에 더 많은 옵션을 구현하지 마십시오).
• pipenv의 마지막 릴리스는 1년 전이었습니다.
  https://pypi.org/project/pipenv/#history , 우리는 무엇에 대해 확신하지 못합니다
  프로젝트가 나아갈 방향.
• Deps를 해결할 때 Pipenv가 느립니다. 이미 동일한 문제가 있습니다.
  콘다와 함께. 그러나 conda는 최근에 개선되었으므로 pipenv는
  시간이 지남에 따라 해당 영역에서도 개선되었습니다.
• 우리는 실험적인 방식으로 pipenv를 지원하려고 할 수 있습니다(우리는 이미
  pipenv 지원으로 준비된 PR 종류), 그래서 우리는 그것을 제거/변경할 수 있습니다.
  어떤 보증.

이러한 결정의 일부는 우리가 pipenv를 구현하면
우리는 영원히 유지해야 합니다. 여러분의 의견을 알려주세요.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/readthedocs/readthedocs.org/issues/3181?email_source=notifications&email_token=ABGUL7JZGO2MZLY7WMZJ6X3QVVQJJA5CNFSM4EAMFA62YY3PNVWWK3TUL52HS4DFVREXG43
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/ABGUL7JU6HHROEZP6IWAE3TQVVQJJANCNFSM4EAMFA6Q
.

그렇다면 시를 지원할 계획은 없나요?

@petersmithca 이제 시를 사용할 수 있어야 합니다 https://poetry.eustace.io/docs/pyproject/#poetry -and-pep-517

내 문서를 작성하기 위해 시와 함께 문서 작업을 읽을 것입니다.

2019년 11월 27일 수요일 오전 11:18 Santos Gallegos [email protected]
썼다:

그렇다면 시를 지원할 계획은 없나요?

이제 시를 사용할 수 있어야 합니다.
https://poetry.eustace.io/docs/pyproject/#poetry -and-pep-517

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/readthedocs/readthedocs.org/issues/3181?email_source=notifications&email_token=ABGUL7P7B5C5HSU4DDSMDNTQV2FTBA5CNFSM4EAMFA62YY3PNVWWK3TUL52HS4DFVEXG43VMVB
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/ABGUL7KI4LUTHHYUITCB7YYLQV2FTBANCNFSM4EAMFA6Q
.

내 문서를 작성하기 위해 시와 함께 문서 작업을 읽을 것입니다.

예, 우리는 시를 직접 호출하지 않지만 pip로 호출됩니다(즉, PEP 517).

오 그래. 멋진 감사합니다

2019년 11월 27일 수요일 오전 11:22 Santos Gallegos [email protected]
썼다:

내 문서를 작성하기 위해 시와 함께 문서 작업을 읽을 것입니다.

예, 우리는 시를 직접 호출하지 않지만 pip로 호출됩니다(즉, PEP
517)

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/readthedocs/readthedocs.org/issues/3181?email_source=notifications&email_token=ABGUL7M2WA2SR2JL54AIIG3QV2GEPA5CNFSM4EAMFA62YY3PNVWWK3TUL52HS4DFVEXG43VMVB
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/ABGUL7OXN4AK63UAIL7TO3LQV2GEPANCNFSM4EAMFA6Q
.

내 이해는 pip가 미래의 어느 시점에서 Pipfile 및 Pipfile.lock 형식을 지원하기 시작할 것이라는 것입니다. 어느 쪽이든 Pipenv를 사용한 종속성 관리가 pip보다 직관적이고 신뢰할 수 있으며 내장된 venv가 마음에 듭니다.

@zbeekman 그 이해에 대한 출처가 있습니까?

지금까지 입력해 주셔서 감사합니다. 이 있으면 도움이 됩니다.

그렇지 않으면 모든 것이 프로젝트에 대해 다른 솔루션을 선택하므로 readthedocs와 같은 도구는 모두 다양한 솔루션을 지원해야 할 수 있습니다.

어느 정도 같은 느낌이 듭니다. RTD는 프로세스 및 도구에 대해 지나치게 독단적일 수 있지만 Python 커뮤니티를 전반적으로 지원하려는 경우 워크플로에 더 많은 유연성이 있어야 합니다.

내가 제기한 한 가지 옵션은 현재 적극적으로 고려되지 않고 있는 pipenv 지원을 "실험적" 기능으로 구현하는 것입니다. 이는 pipenv가 핵심 팀에서 지원되지 않고(지원 요청을 도울 수 없음) pipenv 지원이 중단될 수 있음을 의미합니다(경고와 함께 더 이상 사용되지 않음).

일반적으로 이 시점에서 나는 아마도 pipenv 지원에 대한 하드 패스로 투표할 것이지만 이것은 여전히 ​​많은 요청을 받는 기능입니다.

pipenv 사용자라면 코어 팀에서 더 많은 답변이 필요하다고 생각하는 질문은 "시를 사용하지 않는 이유는 무엇입니까?"입니다. pipenv에 대한 우리의 결정은 일상적인 개발에서 두 도구의 사용자가 아니기 때문에 더 왜곡될 수 있습니다. 따라서 시는 pipenv와 동의어처럼 느껴집니다. RTD만이 실제로 시를 지원합니다.

그 당시 내가 (시가 아니라) pipenv를 사용하기 시작한 이유 중 하나는 통합에서 Pipfile에 대한 광범위한 지원이었습니다. , pyproject.toml 및 시에 대한 지원은 여전히 ​​드뭅니다. 마지막으로 확인했을 때 이제Dependabot이 지원하는 것으로 나타났지만 나머지는 의심스럽습니다. RTD는 실제로 내가 Pipfile에 대한 핵을 알아내야 하는 유일한 곳이었고 시가 더 빨리 지원되는 곳이었습니다.

어떤 도구가 결국 사용자를 이겼는지는 모르겠지만 제 생각에는 사람들이 pip + virtualenv와 같은 것을 간절히 원했고 pipenv가 나타나면 사용하기 시작했습니다. 시는 잘 알려지지 않았고, 내가 그것에 대해 알았을 때 마침내 생태계를 지배하는 하나의 도구가 있다는 것이 산만하다는 느낌을 받았습니다. 나중에 사람들은 pipenv의 결함을 깨닫고 핍으로 돌아가거나 대안을 찾고 시를 발견하기 시작했습니다. 이 과정이 아직도 일어나고 있는 것 같아요. 도구는 시를 알아차리는 것을 따라잡지만 pipenv는 더 일찍 대량 채택되었으며 이미 "모든 곳에서" 지원됩니다.

많은 사람들과 마찬가지로 오늘날 나는 pipenv의 한계를 보고 시로 마이그레이션할 생각을 하지만 사용하는 도구가 따라잡을 때까지 하지 않을 것입니다.