Pipenv: pipenv는 현재 프로젝트의 virtualenv를 어떻게 압니까?

virtualenv의 이름은 프로젝트의 루트 디렉터리 이름에 프로젝트 루트에 대한 전체 경로의 해시를 더한 것입니다. 이렇게 하면 프로젝트를 이동하지 않는 한 고유하고 예측 가능한 이름이 보장됩니다. (AFAICT 이 이름 생성 논리는 의존해서는 안 되는 구현 세부 사항입니다.)

패키지의 특정 버전을 설치하려면 pip 및 requirements.txt와 동일한 구문을 사용하십시오(예: pipenv install django==1.11.0 .

@uranusjr 이것은 디렉토리의 이름을 바꾸면 내 프로젝트의 virtualenv가 손실된다는 것을 의미합니다. 그 나쁜. 디렉토리의 이름을 바꾸는 것은 일반적인 사용 사례일 수 있으며 사용자는 이에 빠지고 환경이 어떻게 작동을 멈췄는지 궁금해할 수 있습니다.

가능한 경우 수정하고 Pipfile에 항목을 만드는 것이 좋습니다. 또는 다른 .pipenv 파일을 만들어 각 프로젝트 디렉터리에 이러한 메타데이터를 저장합니다.

당신은 무엇을 제안합니까?

두 질문에 모두 답해주셔서 감사합니다!

@sachinjain024님 , 로컬 메타데이터 파일에 대해 몇 가지 논의를 했지만 현재로서는 pipenv가 지원하지 않을 것이라는 관리자의 합의가 있었습니다.

프로젝트를 식별하는 디렉토리 경로는 이름이 같은 프로젝트 또는 동일한 프로젝트의 여러 복사본이 환경 상태를 실수로 덮어쓰는 원인이 되었기 때문에 초기에 구현된 것입니다.

실제로 작업을 조용히 덮어쓰는 것보다 위치가 환경의 일부인 문제를 겪는 사람이 훨씬 적습니다. Pipenv는 결국 배포 관리 도구이므로 디렉토리를 이동하는 것은 하나의 명령 수정이어야 합니다.

@nateprewitt 감사합니다. 쉬운 구현으로 빠르게 이동하는 것이 좋습니다. 나중 단계에서 프로젝트 이름을 바꾸면 내 환경이 존재하지 않는다는 의미입니다.

이 상황에서 어떻게 해야 합니까?

1. 환경을 재설정하기 쉽도록 패키지 정보가 있는 Pipfile이 이미 있으므로 환경을 재설정하십시오.
2. 어떻게 든 virtualenv 디렉토리의 이름도 바꾸십시오.
3. ???

이 경우 무엇을 제안합니까? 앞으로 이런 상황에 처할 경우를 대비하여 궁금합니다.

pew cp 를 사용하여 기존 virtualenv를 쉽게 복사할 수 있지만 1. 더 "정규적인" 방법이라고 생각합니다.

@sachinjain024 , 프로젝트 디렉토리를 이동해야 할 때마다 pipenv install 만 실행하면 작동 상태로 돌아갑니다. 이렇게 하면 새 해시를 사용하여 환경을 만들고 이전 설치와 동일하게 잠금 파일의 모든 항목을 다시 설치합니다.

이 작업을 자주 수행하는 경우 pew rm old_project-a3de90 를 사용하여 정리할 수 있습니다.

pipenv 외부에서 가상 환경을 수정하지 않는 한 pew cp 사용하지 않는 것이 좋습니다. 이 경우 "무효 보증" 시나리오를 고려해야 한다고 생각합니다. 우리가 안정적으로 설명할 수 없는 모든 종류의 변경 사항이 있기 때문입니다.

@nateprewitt @uranusjr 감사합니다. 이 티켓을 닫습니다.

이것은 지금까지 pipenv 나온 최악의 아이디어 중 하나입니다. 이유는 다음과 같습니다.

저는 Python이 많은 내부 프로젝트의 테스트 자동화에 사용되는 회사에서 일합니다. 한 테스터는 일반적으로 그 중 12개에서 작업합니다. 관례에 따라 프로젝트의 모든 테스트 코드는 tests 디렉토리에 있습니다. 이것은 각 테스터가 이제 ~/.local/share/virtualenvs/tests-hKjFddnZ 와 같은 가상 환경을 갖게 되었음을 의미합니다. 가상 환경을 전환하는 것을 잊는 것은 인간의 본성이므로 해당 워크스테이션에 있는 사람이 필요한 패키지를 설치했다고 생각하기 때문에 며칠마다 다른 워크스테이션으로 호출됩니다. pipenv install . 그러나 코드의 가져오기가 작동하지 않습니다. 그뿐만 아니라 고아 가상 환경은 시간이 지남에 따라 누적되지만 모두 설명이 불가능한 이름을 가지고 있기 때문에 사용하지 않는 환경을 삭제하는 것인지 실제로 사용되는 환경을 삭제하는 것인지 알 수 있는 방법이 없습니다. 이는 CI에서 매일 수백 개는 아니더라도 수십 개의 가상 환경을 생성한다는 것을 의미합니다. 본질적으로 임의의 이름을 가진 환경을 추적할 수 있는 사람은 없고 환경이 너무 많기 때문에 적어도 하루에 한 번은 모든 환경을 삭제해야 합니다. pipenv 와 우리 회사의 누군가가 그것을 사용하기로 결정한 이 매우 현명한 결정 때문에 우리는 대기 시간에 막대한 비용을 지불합니다...

bashrc / 쉘 구성에서 export PIPENV_VENV_IN_PROJECT=1 를 설정하십시오.
(또는 $PROJECT/.venv에 가상 환경을 생성하도록 쉘 스크립트를 변경한 다음
pipenv는 그것을 가질 것입니다)
2018년 3월 19일 월요일 오전 6시 28분 wvxvw [email protected]에서 다음과 같이 썼습니다.

이것은 지금까지 pipenv에서 나온 최악의 아이디어 중 하나입니다. 이유는 다음과 같습니다.

저는 Python이 많은 테스트 자동화에 사용되는 회사에서 일하고 있습니다.
내부 프로젝트. 한 테스터는 일반적으로 그 중 12개에서 작업합니다. 에 의해
규칙에 따라 프로젝트의 모든 테스트 코드는 tests라는 디렉토리에 있습니다.
이것은 각 테스터가 이제 모든 가상 환경을 가지고 있음을 의미합니다.
~/.local/share/virtualenvs/tests-hKjFddnZ -
엄청난! 가상 환경을 전환하는 것을 잊는 것은 인간의 본성이므로,
며칠마다 다른 워크스테이션으로 전화를 받습니다.
해당 워크스테이션에서 필요한 패키지를 설치했다고 생각하면
pipenv install을 실행했지만 코드의 가져오기가 작동하지 않습니다. 뿐만 아니라
고아 가상 환경은 시간이 지남에 따라 축적되지만 모든
그들 중 설명하기 어려운 이름이 있습니다. 삭제하는지 여부를 알 수 있는 방법이 없습니다.
사용하지 않는 환경 또는 실제로 사용된 환경. 이것
CI에서 수백 개는 아니더라도 수십 개의 가상 환경을 생성한다는 의미입니다.
일일. 아무도 없는 환경을 추적할 수 있는 방법은 없습니다.
본질적으로 임의의 이름이 있고 너무 많은 이름이 있으므로
적어도 하루에 한 번은 모두 삭제하십시오. 우리는 대기 시간에 막대한 비용을 지불합니다.
pipenv와 누군가가 내린 이 매우 현명한 결정 덕분에
그것을 사용하기로 결정한 우리 회사는 ...

—
이 스레드에 가입했기 때문에 이 메시지를 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/pypa/pipenv/issues/796#issuecomment-374211264 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/ABhjqyABdDHCB8WMm-hJwdkNptVlh8fuks5tf7KBgaJpZM4Pp3kf
.

@jtratner 그렇다면 가상 환경을 손으로 만들려면 왜 pipenv 필요합니까?

가상 환경은 그 자체로 작업입니다. 모든 곳에서 절름발이이며 Windows에서는 손상되었습니다(MS Windows에서는 모든 위치에서 기본 홈 디렉토리를 "~"라고 함). 누군가가 PIP와 가상 환경을 다시 실행한다면 전임자의 명백한 오류를 수정할 수 있기를 바랐습니다... 대신 이 혼란에 비호환성 레이어가 곱해졌습니다.

잘못된 가정을 하고 있습니다. Pipenv는 virtualenv 또는 pip를 다시 실행하지 않습니다. 그것은 그것들을 기반으로 합니다.

@uranusjr 독해력 문제입니다. 내가 원하는 것보다 코드를 디버깅하는 데 훨씬 더 많은 시간을 소비하기 때문에 pipenv 가 무엇을 하는지 잘 알고 있습니다. 가상 환경과 PIP를 다시 실행하는 것은 프로젝트의 명시된 목표입니다. 그것을 수정하는 대신 "있는 그대로" 사용하기로 결정한 것은 pipenv 또 다른 큰 실수이며 click 라이브러리를 사용하고 목록은 계속됩니다.

가상 환경과 PIP를 다시 실행하는 것은 프로젝트의 명시된 목표입니다.

누가 이것을 어디에서 진술했습니까?

나는 또한이 동작이 이상하다는 것을 발견했습니다. pipenv 가 virtualenv 디렉토리의 표준 이름을 선택하고 npm 가 node_modules 사용하는 방식과 유사한 현재 디렉토리에 디렉토리를 넣을 것으로 예상했습니다.

@플림 export PIPENV_VENV_IN_PROJECT=1 . 문서를 읽으십시오.

@uranusjr 나는 https://docs.pipenv.org 및 https://docs.pipenv.org/basics/ 를 모두 읽었고, 내가 놓친 경우가 아니면 virtualenv 디렉토리가 설치된 위치를 언급하지 않습니다. 또한 프로젝트 디렉토리의 이름을 바꾸거나 이동하면 virtualenv 디렉토리를 다시 생성해야 한다고 경고하지 않습니다.

PIPENV_VENV_IN_PROJECT 는 표준 라이브러리에 포함된 venv 사용하지 않고 다른 프로젝트인 virtualenv 사용하기 때문에 pipenv 라는 이름이 혼동되기 쉽습니다.

저는 이 프로젝트에 익숙해지면서 제가 넘어진 것들에 대한 피드백을 제공하려고 합니다.

@Flimm 요점은 이 정보를 추상화하는 것입니다. virtualenvs를 관리하는 다른 도구가 어떻게 작동하는지 알고 있다면 virtualenvs의 폴더를 이동하면 찾을 수 없다는 것을 이미 알고 있어야 합니다. 익숙하지 않은 경우 처음부터 이것을 파헤치지 않을 것입니다.

우리가 virtualenvs를 생성하는 데 사용하는 백엔드 라이브러리와 환경 변수의 이름 지정은 전자가 그다지 중요하지 않고 후자가 널리 사용되는 속기입니다. 세부 사항이 중요하지만 이것은 누구에게도 문제를 일으키지 않는 것 같으며, 귀하의 주된 반대는 우리가 파이썬 실행 파일을 폴더에 넣는 데 사용하는 백엔드를 확신하지 못하는 것에 근거한 것 같습니다. 버그가 발생하면 보고해 주십시오. 우리는 환경 변수를 변경하지 않을 것입니다 _단지 왜냐하면_.

환경 변수는 다음 문서에서 쉽게 사용할 수 있습니다. http://pipenv.readthedocs.io/en/latest/advanced/#configuration -with-environment-variables 그것

@techalchemy 다른 도구로는 virtualenvwrapper 와 같은 것을 의미한다고 생각합니다. 나는 virtualenvwrapper 를 사용하지 않고 몇 년 동안 갔다. Node/NPM의 node_modules 패턴에 익숙한 Python 개발자의 수가 virtualenvwrapper 또는 pipenv 익숙한 Python 개발자의 수보다 많을 것이라고 추측합니다.

다른 문제 #1919에서 PIPENV_VENV_IN_PROJECT 의 이름 지정에서 virtualenv 대신 venv 에 대한 혼동을 주는 참조에 대해 언급했습니다. 말하자면, 나는 당신이 내가 생각하는 위치를 완전히 유지하지 못합니다.

어쨌든 원래 문제의 질문에 대한 답변이 제공됩니다. 나는 이 토론을 연장하고 싶지 않습니다. 원하시면 마지막으로 말씀해 주십시오.

나는이 잘못된 관객 이해하지만이 토론이 진행되기 때문에 ... 음, 나는 생각하지 않는다 node_modules 에 대한했다 영감 pipenv , 그리고에 대한 virtualenv . 내 추측은 역사적으로 올바르지 않을 수 있지만 rbenv 와 virtualenv 와 함께 작업해야 하는 경우 virtualenv 가 이해가 없는 나쁜 사본처럼 느껴진다고 말할 수 있습니다. rbenv 에 의해 개선된 초기 프로토타입일 수도 있습니다. 두 경우 모두 rbenv 비해 virtualenv 는 웃음거리이며 그 이유는 다음과 같습니다.

각 환경에 대한 패키지를 복사합니다. 이것은 어리석고 느리고 혼란스럽습니다. 그것은 단지 잘못된 디자인 결정일 뿐이지만 결정 부족일 가능성이 더 큽니다. 누군가가 이러한 패키지를 임의의 디렉토리에 넣는 일부 코드를 작성했기 때문에 그렇게 되었습니다. 게다가 Windows에서는 실제로 작동하지 않습니다. Windows에서 실제로 테스트된 적이 없다는 점에서... 이것에 대해 웃기는 점 중 하나는 OS를 테스트하고 Windows에서 실행되는 것을 발견하면 홈 디렉토리를 ~ 설정한다는 것입니다. 이 기본값은 나중에 일부 환경 변수에 의해 재정의될 수 있지만 실제로 감독되고 깨끗한 환경에서 자동화를 실행하려는 경우... virtualenv 는 단순히 동일한 디렉토리에 패키지를 설치하지 않습니다.

그래서... pipenv 는 requests 와 같은 인간을 위한 도구라고 주장합니다 ... 제 생각에는? 그래서 선배님들의 미숙한 노력을 좀 더 보완해야 할듯... 글쎄요.. 전작들과 똑같은 기능을 하는 프로그램을 만들고 싶다면 그렇게 하는게 맞는거 같습니다. ? 그래도 virtualenv 의 쓰레기를 버리지 않고 그대로 사용합니다. 래퍼는 래핑된 프로그램의 일부 기능을 사용하는 것을 허용하지 않거나 더 어렵게 만든다는 점에서 래핑된 프로그램과 다릅니다...

내 인생에서 자동화를 시도하는 많은 시도를 보았지만 짜증이 났습니다. 하지만 여러분은 별을 노리고 있습니다. 유용한 정보를 입력하기도 전에 사이트에 과분한 평가를 모두 올려 놓았습니다. 그러나 당신은 약속을 지키지 않습니다. 실제로는 실제 작업을 수행하지 않고 단순히 여론을 조작합니다. 이제 자동화를 수행해야 하는 프로그래머는 GitHub에서 더 많은 "좋아요"를 받기를 원했기 때문에 또 다른 악에 직면해야 합니다...

@wvxvw 실제로 당신은 틀 5년 (4년, 아래 참조) 정도 앞서므로 영감을 받을 수 없습니다. 또한 그것들은 근본적으로 다른 것들이며, 결국 비슷한 목표를 달성할 뿐입니다. 당신이 찾고 있는 것(rbenv에서 영감을 받은 런타임 관리 도구)은 pyenv입니다.

또한 virtualenv가 다른 도구와 동등하지 않은 것과 관련하여 십(10)년 동안 사용되었다는 사실을 알고 계십니까? 소프트웨어 개발 요구 사항은 많이 변하고, 그 가정은 점차 구식이 되었고 아무도 그것을 대체하려고 나서지 않았습니다. 한 단계 더 올라갈 만큼 신경을 쓰고 있습니까?

나는 모든 사람이 말할 기회를 가질 자격이 있다는 것을 이해하지만, 주제에 대한 최소한의 이해 없이 토론에 참여하고 곧바로 손가락질을 시작하는 것은 Pipenv, virtualenv 및 Python 패키징 시스템 전체의 기여자에게 상당히 무례한 일입니다. 이 작업을 수행하지 마십시오.

편집 : 나는 약간의 파기를했습니다. virtualenv의 초기 릴리스인 0.8은 2007년에 만들어졌고 rbenv의(0.1)은 2011년이었으므로 5년이 아니라 4년 차이입니다.

@wvxvw 모욕을

프로젝트 경로를 변경하고 원래 virtualenv 매핑을 잃은 후에도 같은 문제가 발생하여 이 스레드를 읽었습니다. 먼저 pipenv 팀의 노고에 감사드립니다. 이 토론에 대해 공유하고 싶은 몇 가지 의견이 있습니다.

1. 문서는 실제로 프로젝트 경로와 환경 간의 매핑 메커니즘을 지적해야 하며 최소한 changing project path would cause unmapping the original env 사용자에게 경고해야 합니다.

2. Pipfile에서 환경에 대한 경로를 수동으로 설정할 수 있다면 더 좋을까요? 사람들이 동일한 환경을 수동으로 사용하기 위한 몇 가지 특별한 요구 사항이 있을 수 있음을 의미합니다.

여러분과 공유하기 위한 제 의견일 뿐입니다.

pipenv를 사용하는 방법은 완전히 불분명합니다. 하나의 프로젝트에 여러 가상 환경이 있어야 합니까? 프로젝트 간에 가상 환경을 공유해야 합니까? python 버전이 해당 프로젝트에만 필요한 경우 pipenv를 사용하여 특정 프로젝트에 대해 다른 python 버전을 어떻게 설치합니까? 이 스레드에서 모두는 다른 사람들에 대해 많은 것을 가정하고 다른 사람들이 어디에서 왔는지 이해하려고 노력하지 않습니다. 홈페이지에서 pipenv의 칭찬을 읽으면서 도움이 될 것이라고 믿었습니다. 대신, 나는 그것과 씨름하는 5일을 낭비했고, 지금은 그것이 적어도 어느 정도 결정적이기 때문에 pyenv로 돌아갈 것이라고 생각합니다.

하나의 프로젝트에 여러 환경을 사용하려면 tox를 사용하십시오. 주요 개발 환경에는 pipenv를 사용하고 여러 Python 버전에서 테스트하려면 tox를 사용하세요.

@ashnur 당신은 분명히 할 일이 필요합니다. 자원 봉사자들이 운영하는 오픈 소스 프로젝트에 부정적인 내용을 퍼뜨리는 대신 유용한 것을 기여해 보는 것은 어떻습니까?

@uranusjr
이 해시 일이 어디입니까?

프로젝트를 진행 중이며 경로의 해시를 계산해야 합니다.

@devxpy 네 ,

나는 너희들이 pipenv로 virtualenv를 설정하는 방법에 대한 기본적인 튜토리얼을 넣어야 한다고 생각한다. 왜냐하면 그것이 사람들에게 더 쉽기 때문에 더 많은 사람들이 그것을 사용할 것이지만 그것이 혼란을 야기한다면 더 많은 사람들이 그것을 사용하지 않을 수 있고 다른 것을 찾을 수 있기 때문이다. 프로젝트를 빌드하는 언어 또는 방법

@uranusjr Pipenv가 프로젝트 디렉토리에 기본적으로 virtualenv를 생성하지 않는 이유는 무엇입니까? 내가 보기에는 프로젝트 이름이 변경/이동/삭제될 때 고아 환경 문제가 해결됩니다. 게다가 npm처럼 작동하기를 (다소 정당하게) 기대하는 사람들에게는 덜 혼란스러울 것입니다.

아마도 전통 외에 이 접근 방식을 선호하는 이점이 있습니까?

pipenv install 명령 전에 .venv 디렉토리를 생성하기만 하면 됩니다. pipenv 설치에 대한 —venv 또는 —dot-venv 옵션은 실제로 환영받을 것입니다. :)

2018.10.9부터 이 작업을 수행하는 또 다른 방법이 있습니다. 가상 환경에 대한 경로가 포함된 .venv 파일 을 추가할 수 있습니다. (교활한 새로운 기능!)

@andrewpeterprifer 우리는 이것을 하곤 했고 어떤 사람들은 매우 강하게 거부했기 때문에 그것을 변경해야 했습니다. 우리는 하나의 접근 방식 또는 다른 접근 방식을 선택해야 하며, 프로젝트 디렉토리 내부에 가상 환경을 두지 않는 것이 더 나은 기본값임을 인정해야 했습니다.

ps 이에 대한 FAQ 항목을 작성하는 데 관심이 있으신가요? 몇 단락이 걸릴 수 있지만 누군가가 텍스트를 다듬고 PR을 제출하는 데 시간을 할애하겠다고 약속하면 기꺼이 설명하겠습니다.

@uranusjr 왜 더 나은 기본값인지 매우 궁금합니다. 저는 파이썬에 대해 상대적으로 멍청한 사람이고 이제 모범 사례에 대해 분명한 것을 놓치고 있는 것 같습니다. :) 감사 해요!

추신.: 왜 그런 일이 일어나는지 설명하면 FAQ 항목을 작성할 수 있습니다. ;)

2018.10.9부터 이 작업을 수행하는 또 다른 방법이 있습니다. 가상 환경에 대한 경로가 포함된 .venv _file_을 추가할 수 있습니다. (교활한 새로운 기능!)

@andrewpeterprifer 우리는 이것을 하곤 했고 어떤 사람들은 매우 강하게 거부했기 때문에 그것을 변경해야 했습니다. 우리는 하나의 접근 방식 또는 다른 접근 방식을 선택해야 하며, 프로젝트 디렉토리 내부에 가상 환경을 두지 않는 것이 더 나은 기본값임을 인정해야 했습니다.

ps 이에 대한 FAQ 항목을 작성하는 데 관심이 있으신가요? 몇 단락이 걸릴 수 있지만 누군가가 텍스트를 다듬고 PR을 제출하는 데 시간을 할애하겠다고 약속하면 기꺼이 설명하겠습니다.

죄송합니다 ... pipenv로 만든 가상 환경이 있는 프로젝트 폴더를 이동해야 하는 것과 똑같은 필요가 있습니다.

현재 다음을 수행하고 있으며 전혀 문제가 없습니다.

• 내가 원하는 곳으로 프로젝트 폴더를 이동
• C:\Users\user\.virtualenvs에서 방금 이동한 프로젝트와 연결된 가상 환경의 폴더를 삭제합니다.
• cmd를 통해 새 프로젝트 폴더 위치로 이동하고 pipenv install(또는 pipenv 셸을 실행한 다음 pipenv sync)을 실행합니다.

모든 것이 정상 작동합니다. 이것은 나쁜 습관입니까?

@uranusjr 주석과 관련하여 새 기능을 올바르게 이해했다면 .venv 파일(원하는 가상 환경에 대한 경로 포함)을 프로젝트 폴더에 추가해야 합니까? 이렇게 하면 이전에 언급한 모든 단계를 수행하지 않아도 됩니까? 그렇다면 훌륭합니다!!
그렇다면 가상 환경을 처음 생성할 때 프로젝트 폴더에 자동으로 그런 파일이 생성된다면 더 좋지 않을까요?

추신: 또한 FAQ를 작성할 의향이 있습니다.

사실, @gioxc88 의 아이디어가 좋은 것 같아요. 새로 생성된 virtualenv는 프로젝트 루트 아래에 .env 파일을 자동으로 생성할 수 있고 PATH 와 같은 환경 설정을 포함합니다. 개발자에게 환경을 보다 투명하게 만들고 재구성하는 더 편리한 방법을 제공합니다.

질문에 함께 답변해 드리겠습니다. 접근 방식은 나쁘지 않습니다(IMO, 저도 같은 설정을 사용합니다). 그러나 모르는 사용자가 걸려 넘어지기 쉽습니다.

그것을 생각하는 한 가지 방법은 프로젝트를 버전 제어(예: Git)에 넣는 것을 고려하는 것입니다. 환경이 프로젝트 루트에 생성되면 당연히 저장소 루트에 있을 것입니다. 이 설정에 익숙한 나와 나 같은 사람들은 .venv 디렉토리가 체크인되지 않도록 .gitignore (또는 전역 무시 구성)에 규칙을 추가해야 한다는 것을 분명히 알고 있지만 순진한 사용자는 그렇지 않으며 우연히 환경을 매우 쉽게 확인할 수 있습니다. 이것은 프로젝트 관리에 나쁠 뿐만 아니라 (더 중요하게) 로컬 정보를 노출하여 잠재적인 공격에 대한 벡터를 제공합니다. 따라서 생성된 파일을 프로젝트 디렉토리에 넣지 않는 것이 프로젝트 관리 도구의 일반적인 규칙입니다. 생태계를 처음부터 설계하는 경우(예: NPM의 node_modules ) 이를 수행하는 것이 괜찮을 수 있지만(예: NPM의

기본적으로 환경이 프로젝트 루트 외부에서 생성되는 경우 프로젝트를 게시할 때(예: GitHub에 푸시) 걱정할 가능성이 한 가지 줄어듭니다. 그것은 (프로젝트 내 환경을 선호하는) 우리의 삶을 조금 더 어렵게 만들지만 위험 관점에서 일어날 수 있는 최악의 상황은 실수로 프로젝트를 이동하고 환경을 깨뜨리거나 프로젝트가 제거될 때 환경을 제거하는 것을 잊는 것입니다. . 어느 쪽이든 실수로 잠재적으로 민감한 환경 정보를 GitHub에 푸시하는 것보다 훨씬 더 쉽게 복구할 수 있습니다.

.venv 파일 기능은 여전히 ​​새로운 기능이며(일 전에 출시됨), 우리는 여전히 이를 가장 잘 활용하는 방법을 모색하고 있습니다. 여전히 .venv 디렉토리와 동일한 문제가 있지만 그렇게 나쁘지는 않습니다. 이 기능 자체가 정말 마음에 듭니다. 이 기능을 사용하여 사용자 경험을 개선할 수 있기를 바랍니다. 하지만 여기에서 고려해야 할 사항이 여전히 많습니다.

안녕. 저에게 .venv 디렉토리(이전 기능)와 .venv 파일(새 기능)은 괜찮지만 pipenv install 명령에 옵션이 있으면 매우 감사하겠습니다.

다음과 같은 것:

pipenv install

~/.local/

pipenv install --venv

$PWD/.venv 디렉토리에 설치합니다.

pipenv install --venv-dir /my/custom-path

/my/custom-path 설치됩니다.

새로운 기능을 원하시면 ~/.peeps 개선 제안을 하여 적절하게 제안해 주세요. 다양한 문제에 무작위로 흩어져 있는 개선 제안을 하지 마십시오. 추적할 수 없습니다.

@uranusjr 자세한 답변 감사합니다! 내 호기심을 충족시키기 위해 어떤 종류의 로컬(잠재적으로 민감한) 정보가 체크인된 python venv에 의해 노출될 수 있습니까? node_modules가 체크인되면 성가신 일이라는 데 동의하지만 일반적으로 여기에는 로컬 정보가 포함되지 않습니다.

Python 가상 환경에는 여러 셸 스크립트(예: activate )가 포함되어 있습니다. 많은 사람들이 데이터베이스 암호, 다른 구성 파일 경로 등을 지정하기 위해 환경 변수를 추가하기 위해 스크립트를 수정합니다. 가상 환경에서 스크립트를 수정하는 것은 모범 사례에 위배되지만 그럼에도 불구하고 사람들은 이 작업을 수행합니다. - 개인적인 경험).

또한 node_modules 민감한 정보가 포함되어 있지 않을 수 있습니다. 생태계를 처음부터 구축할 때의 또 다른 이점입니다. Python 가상 환경은 불행히도 이것이 일반적인 문제가 되기 전에 발명된 방식입니다(당시에는 VCS를 전혀 사용하지 않는 경우 이미 전문가였습니다).

pipenv가 올바른 virtualenv를 어떻게 알고 있는지 이해하려고 하는 동안 여기에 도착했습니다. :)

토론해주셔서 감사합니다. 아마도 메인 페이지(예: 여기 )에서 프로젝트 경로의 이름을 바꾸면 virtualenv 바인딩의 기본 메커니즘이 중단되도록 지정하는 것이 좋습니다.

모든 문서 페이지는 기여를 위해 열려 있습니다. 부탁하지 말고 하세요 :)

그럴 게요!

@uranusjr 이것은 디렉토리의 이름을 바꾸면 내 프로젝트의 virtualenv가 손실된다는 것을 의미합니다. 그 나쁜. 디렉토리의 이름을 바꾸는 것은 일반적인 사용 사례일 수 있으며 사용자는 이에 빠지고 환경이 어떻게 작동을 멈췄는지 궁금해할 수 있습니다.

가능한 경우 수정하고 Pipfile에 항목을 만드는 것이 좋습니다. 또는 다른 .pipenv 파일을 만들어 각 프로젝트 디렉터리에 이러한 메타데이터를 저장합니다.

당신은 무엇을 제안합니까?

두 질문에 모두 답해주셔서 감사합니다!

두 가지 모두 질문해 주셔서 감사합니다. 나는 또한 같은 문제가 발생합니다,

잘못된 디렉토리에서 pipenv를 초기화하고 올바른 디렉토리에서 virtualenv 디렉토리를 사용해야 하는 경우 pipenv --venv 를 수행하여 virtualenv 경로를 얻을 수 있고 PIpfile 및 Pipfile.lock 이동할 수 있습니다. 올바른 디렉토리로 이동합니다.

echo ${PATH_OBTAINED_FROM_PREVIOUS_COMMAND} > .venv 가 올바른 디렉토리에 있고 제대로 작동해야 합니다.

오늘 나는 상위 디렉토리에 pipfile이 있으면 pipenv가 export PIPENV_VENV_IN_PROJECT=1 환경 변수를 무시하고 대신 상위 디렉토리에 venv를 설치한다는 사실을 알게 되었습니다. 2018.11.26 릴리스에 있습니다. 상위 디렉토리에서 pipfile을 제거하면 pipenv는 문서화된 대로 작동합니다.