Pipenv: 가능한 경우 virtualenv 대신 venv를 사용하십시오.

나는 그렇게 생각하지 않습니다. 개인적으로 virtualenv 명령을 사용하는 것을 선호합니다.

하지만 두 옵션을 동시에 사용할 수는 없을까요? 자연스럽게 소스를 검색해 보니 환경을 만드는 데 사용된 명령을 제외하고는 Virtualenv와 특별히 결합된 것이 없습니다. VIRTUALENV는 항상 기본이 될 수 있지만, 사용자가 (예를 들어) 통과 할 수 --venv 생성하기 .venv 가진 python3 -m venv 대신 virtualenv .

솔직히 pipenv에만 의존하고 virtualenv 또는 venv가 사용되는지 여부는 신경 쓰지 않지만 가능한 경우 내장 기능을 활용할 수 있다고 생각했습니다.

@kennethreitz 가 여기에서 그의 의견을 재고할 것을 촉구합니다. 표준 문서에서는 virtualenv 대신 python3 -m venv를 사용하는 것이 좋습니다. 나는 virtualenv를 사용하기 때문에 pipenv를 사용하는 것을 개인적으로 연기합니다. 저는 Python 3만 사용하고 요즘에는 venv 만 사용합니다.

@bulletmark 이제 Pipenv는 거의 모든 Virtualenv 관리를 Pew에 위임하므로 전환하기가 훨씬 더 어렵지만 Pew가 venv 를 지원할 계획이 있으므로(berdario/pew#67) 여전히 기회가 있습니다. Pew가 작동하도록 할 수 있다면 Pipenv에서 venv 지원을 구현하는 것이 훨씬 더 쉬울 것입니다.

@uranusjr 잘 들립니다!

저는 개인적으로 venv 사용한 적이 없으므로 이에 대한 우려가 있습니다. 그래도 좋은 건 확실해요.

일이 잘 진행되고 있습니다. 깨지지 않은 것을 변경할 필요가 없습니다.

내 시스템 이 고장났기 때문에 결국 이 스레드를 찾았습니다.

Python 3.X에서 virtualenv 로 환경을 만든 다음 Python 3.Y로 업그레이드하면 Python에 필요한 공유 라이브러리가 더 오래 있다는 것을 알고 있기 때문에 virtualenv가 손상됩니다. 사용 venv 그냥 실행할 수 python3 -m venv --upgrade .

이것은 좋은 기능이 될 것입니다.

이것은 확실히 좋으며 Python의 방향과 일치합니다.

venv를 사용하지 않고 (대신 virtualenv를 사용하는) 저에게는 총체적 난국입니다. 저는 Pipenv를 사용할 수 없습니다. 나는 dhouck이 위의 불만에 대해 위에서 발견한 것처럼 파이썬 바이너리를 복사하면서도 공유 라이브러리에 의존하는 답답한 동작 때문에 virtualenv를 사용할 수 없습니다. 이것은 virtualenvs를 항상 중단시키고(시스템 python이 업데이트될 때마다 바이너리가 매달려 있는 상태로 남음), 아무런 이점도 없이 python 바이너리를 불필요하게 복사합니다.

pipenv가 Python의 미래인 경우 Python 3에서 venv를 사용하도록 기본 설정되어야 합니다(사용하지 않을 때 경고). Python 3에 내장되어 있으며 권장되는 도구입니다. Pipenv가 이제 권장 도구이기도 하지만 venv를 사용하지 않는다는 것은 매우 이상한 일입니다.

venv는 본질적으로 Python 자체의 일부이기 때문에 Python의 내부에 액세스할 수 있으므로 훨씬 적은 수의 해킹으로 올바른 방식으로 작업을 수행할 수 있습니다. 예를 들어 virtualenv는 Python 인터프리터 바이너리를 가상 환경에 복사하여 격리된 것으로 생각하도록 속여야 하지만 venv는 정상적인 위치에서 Python 바이너리가 읽어야 하는 구성 파일을 사용하여 작동해야 함을 알 수 있습니다. 가상 환경에 있는 것처럼. 따라서 venv는 Python 개발자의 축복과 지원으로 virtualenv가 올바르게 수행되었다고 생각할 수 있습니다.

출처: https://www.reddit.com/r/learnpython/comments/4hsudz/pyvenv_vs_virtualenv/

나는 berdario/pew#173을 시작했지만, 진전을 이룰 시간이 많지 않았습니다. 위에서 언급했듯이 Pipenv는 Pew가 지원하면 자동으로 지원합니다. venv를 Pipenv로 가져오는 데 관심이 있는 사람이 있다면 도움을 받고 싶습니다. 지금 가장 중요한 문제는 테스트를 통과하는 것입니다.

venv 지원에 대한 빠른 업데이트: 적어도 가까운 장래에는 일어나지 않을 것입니다. venv 는 단순히 이것을 가능하게 하기에 충분하지 않습니다. 이 문제에 정말로 관심이 있다면 Python 버그 추적기로 이동 하여 도움을 요청하십시오. 그렇지 않으면 virtualenv 고수하십시오.

venv는 Python에 권장되는 도구이며 virtualenv와 같이 손상되지 않았습니다(다시: python 바이너리를 복사한 다음 python libs 업데이트 시 중단됨). 당신이 링크한 버그는 venv와 virtualenv를 결합하는 것에 관한 것인데, 이것은 우리가 요구하는 것이 아닙니까?

불행히도 도구가 virtualenv를 기반으로 구축하는 것은 매우 일반적입니다. 예를 들어 Travis는 원래 기자가 언급한 대로 virtualenv를 사용하여 빌드 환경을 만듭니다. 또한 Pipenv를 설치하는 데 권장되는 방법 중 하나인 Pipsi의 기반이기도 합니다. venv가 내부에서 잘 작동하지 않는 경우. 모르는 곳에 많이 있습니다. Venv 지원은 virtualenv와 잘 작동하지 않으면 절반이 깨져 예상치 못한 방식으로 당신을 물릴 것입니다.

나는 그것을 이해하지만 이 시점에서 Pipenv가 권장되고 venv가 권장되며 그들은 일종의 충돌입니다. 아주 이상한 상태입니다.

나는 그것이 이상한 상태에 있다는 것에 전적으로 동의합니다. 그래서 그것을 고치려고 노력하고 있습니다 :) 고쳐지지 않을 것이라는 말은 아니지만 먼저 업스트림 변경이 필요하고 그들이 될 때까지 내가 할 수 있는 일은 없습니다 일어나 다. 이 링크를 게시하는 이유는 작업을 중단하기 위한 핑계가 아니라 사람들에게 이 상황을 개선하기 위해 먼저 노력해야 할 부분을 알려주기 위한 것입니다.

그렇다면 이 문제를 계속 열어두는 것이 너무 미친 짓이 아닐까요?

이것은 pipenv 문제가 아니라 퓨 문제입니다.

venv는 단순히 이것을 가능하게 하기에 충분하지 않습니다. 이 문제에 정말로 관심이 있다면 Python 버그 추적기로 이동 하여 도움을 요청하십시오.

venv의 문제가 아니라 virtualenv의 문제입니다. 문제 추적기 아래에 몇 가지 설명 을 게시
cc @uranusjr

라는 말이 있습니다 ->
venv를 사용하여 먼저 virtualenv를 만든 다음 pipenv install 를 실행합니다. 예를 들어:

mkdir -p /tmp/try
cd /tmp/try
python3 -m venv .venv
pipenv --venv  # /tmp/try/.venv
pipenv install xxx

🙈

참고 사항:

위의 해결 방법은 대부분 작동하지만 pipenv run ... activate_this.py 아래에 .venv/bin activate_this.py 이 없기 때문에 pipenv run ... 실패합니다. 문제 21496을 믿어야 한다면 이 파일을 venv에 추가할 계획이 없습니다. 따라서 pew가 이 문제를 해결하더라도 pipenv에는 여전히 문제가 있을 수 있습니다.

virtualenv를 사용하여 macOS에서 system tk 모듈을 사용하는 것은 불가능합니다. 그러나 venv를 사용하면 가능합니다.
pipenv와 함께 venv를 사용하고 싶습니다(선택 사항일 수 있음).

참조: #1416

냉소적으로 들리지는 않지만 누군가가 실제로 그렇게까지 신경을 쓰는 경우 이를 지원하는 코드를 실제로 작성하기를 강력히 원합니다. 나는 이것에 대해 "강하게" 느낀다고 말하는 많은 사람들을 만났지만, 내가 아는 한 나는 실제로 무엇이든 할 수 있는 유일한 사람입니다. 그리고 나는 실패했다. 이것은 생각만큼 간단하지 않습니다. 더 잘할 수 있다고 생각되면 무언가를 하십시오. 원하지 않으면 얻을 수 있는 것을 가져오세요.

(kenneth와 나, 그리고 아마도 erin과 nate도 프로젝트 초기에 venv를 사용하여 이 작업을 시도했지만 호환성 문제로 인해 실패했습니다)

이것은 좋을 것입니다. 모두가 동의합니다. 플랫폼과 파이썬 버전에서 작동하는 것을 보고 싶습니다.

venv가 virtualenv보다 더 나은 선택이 될 수 있는 다른 이유를 지적하고 싶습니다.

virtualenv 구현의 더 추악한 측면 중 하나는 생성된 Python 버전에 관계없이 모든 virtualenv에 사용되는 자체 사이트 모듈 복사본이 있어야 한다는 것입니다.
-- https://github.com/pypa/virtualenv/issues/228#issuecomment -4165148에서

이것은 예를 들어 rlcompleter 가 기본적으로 비활성화되어 있다는 것을 의미하며 이는 제 생각에 엄청난 유용성 손실입니다.

또한 이것은 여러 사용자에게 영향을 미치는 문제이므로 업스트림에서 일부 변경 사항이 발생하기를 기다리고 있더라도 문제가 해결될 때까지 열어 두는 것이 좋습니다.

다시. 우리는 그것이 더 좋을 것이라는 것을 알고 있습니다. 그것은 실제로 가능하지 않습니다. 많은 사용자 세그먼트의 기능을 완전히 중단하거나 일부 사용자가 readline 기능을 켜야 하는 것보다 더 부정적인 영향을 미치는 것은 무엇이라고 생각하십니까?

나는 이것이 불편하다고 확신합니다. 또한 이것을 요구하는 사람들만 있는 것 같지만 작동하는 구현을 제공할 사람이 아무도 없다는 것 또한 불편합니다. 우리는 시도했습니다. 무언가가 크게 바뀔 때까지 우리는 venv를 지원할 계획이 없으므로 이 문제를 열 ​​계획이 없습니다.

@techalchemy 내가 올바르게 이해한다면 pypa/virtualenv#1095가 이에 대해 논의할 올바른 장소입니까?

맞는 것 같습니다. tox에 해결 방법이 있는 것을 보았으므로 누군가 포팅하면 작동할 수 있습니다.

좌석! 무슨 토론.. 이 퓨 일이 그렇게 중요하지 않다면 virtualenv와 함께 그것들을 모두 삭제하고 pipenv, venv 및 python이 모두 서로 추천하므로 함께 손을 잡을 수 있습니까?

파이썬을 위한 종속성 관리/가상 환경 솔루션은 현재 너무 험난한 지형이며 약간의 희생을 감수해야 합니다. imho.

이것은 아직 virtualenv 사용을 중단할 준비가 되지 않은 많은 사람들을 놀라게 할 수 있지만 다가오는 주요 릴리스 중 하나를 위해 계획될 수 있습니다(기술적으로 가능한 경우). 변경은 불가피하며 시간 문제일 뿐입니다.

@doganmeh 우리는 virtualenv를 완전히 포기하고 Python 3.3 이상만 지원하는 동등한 제품을 만들 수 있지만 다른 프로젝트를 만드는 것이 더 쉬울 것이라고 생각합니다.

참고 사항:

위의 해결 방법은 대부분 작동하지만 pipenv run ... activate_this.py 아래에 .venv/bin activate_this.py 이 없기 때문에 pipenv run ... 실패합니다. 문제 21496을 믿어야 한다면 이 파일을 venv에 추가할 계획이 없습니다. 따라서 pew가 이 문제를 해결하더라도 pipenv에는 여전히 문제가 있을 수 있습니다.

그게 정말 필요한가요? venv를 사용하여 가상 환경을 만든 후에는 이를 사용하기 위해 활성화할 필요가 없습니다. venv/bin 디렉토리에서 python 바이너리를 사용하여 실행하기만 하면 됩니다.

FWIW, 이것은 관련이 있습니다(그리고 나를 여기로 데려온 것): http://matplotlib.org/faq/osx_framework.html

virtualenv 에서는 프레임워크 빌드( virtualenv bug #54 , virtualenv bug #609 )에서 환경이 생성된 경우에도 non-framework 빌드가 사용됩니다.

해결책은 virtualenv를 사용하지 않고 대신 stdlib의 venv 를 사용하는 것입니다. 이는 유사한 기능을 제공하지만 이 문제를 나타내지 않습니다.

Python 2.7/virtualenv 지원을 중단하는 것은 특히 끔찍한 생각처럼 들리지 않습니다. pipenv 가 지원이 만료되지 않은 Python 버전의 stdlib에 의존하도록 허용한다면 말입니다. pipenv 도구 모음의 다른 부분을 손상시키지 않는 한 유지 관리자가 쉽게 고칠 수 없습니다. 2.7 지원을 별도의 분기/패키지로 옮길 수도 있습니까?

실제 코드를 제공하고 싶지만 그렇게 하는 데 필요한 경험이나 시간이 없다고 생각합니다. :frow: 내가 할 수 있는 최선은 현재 토론에 추가하는 것입니다.

여기에 내 목소리를 추가합니다. @dmtucker 와 같은 문제로 인해 방금 이것을

저는 현재 Mac에서 이 프로젝트를 위해 pipenv를 완전히 무시하고 지금은 venv를 사용하여 환경을 직접 만들고 있습니다.

+1 venv를 사용합니다.
virtualenv에는 많은 wontfix 버그가 있습니다.
pipenv는 Windows Store의 Python 3.7이 포함된 Windows 10에서 완전히 유용합니다(virtualenv bug#1362 ).

virtualenv가 venv 모델로 이동 중입니다. https://github.com/pypa/virtualenv/issues/1366 참조

---------- 전달 된 메시지 ---------
보낸 사람: Dan Ryan 알림 @github.com
날짜: 2018년 11월 26일 월요일 오후 2:39
제목: Re: [pypa/pipenv] 가능한 경우 virtualenv 대신 venv 사용(#15)
받는 사람: pypa/pipenv [email protected]
참조: 구독 [email protected]

맞는 것 같습니다. tox에 해결 방법이 있는 것을 보았으므로
누군가 그것을 이식했다

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