venv, pyvenv, pyenv, virtualenv, virtualenvwrapper, pipenv 등의 차이점은 무엇입니까?

venv, pyvenv, pyenv, virtualenv, virtualenvwrapper, pipenv 등의 차이점은 무엇입니까?

---

Python 3.3은 표준 라이브러리에 새 패키지를 포함합니다 venv. 그것은 무엇을하고, 정규식과 일치하는 다른 모든 패키지와 어떻게 다른 (py)?(v|virtual|pip)?env가요?

---

표준 라이브러리에없는 PyPI 패키지 :

• virtualenvPython 라이브러리를위한 격리 된 Python 환경을 만드는 매우 인기있는 도구입니다. 이 도구에 익숙하지 않은 경우 매우 유용한 도구이므로 배우는 것이 좋습니다. 나머지 답변에 대해 비교해 보겠습니다.

  디렉토리 (예 :)에 여러 파일을 설치 한 env/다음 PATH환경 변수를 수정하여 사용자 정의 bin디렉토리 (예 :)를 접두사로 지정하여 작동합니다 env/bin/. python또는 python3바이너리 의 정확한 사본 이이 디렉토리에 배치되지만 Python은 환경 디렉토리에서 먼저 경로에 상대적인 라이브러리를 찾도록 프로그래밍되어 있습니다. Python의 표준 라이브러리의 일부는 아니지만 PyPA (Python Packaging Authority)의 공식적인 축복을 받았습니다. 활성화되면를 사용하여 가상 환경에 패키지를 설치할 수 있습니다 pip.

• pyenvPython 버전을 분리하는 데 사용됩니다. 예를 들어 Python 2.6, 2.7, 3.3, 3.4 및 3.5에 대해 코드를 테스트 할 수 있으므로 이들간에 전환 할 수있는 방법이 필요합니다. 활성화되면 Python 명령 ( , )과 일치하는 특수 파일이 있는 PATH환경 변수 앞에를 붙 입니다. 이것은 Python에서 제공하는 명령의 복사본이 아닙니다. 환경 변수, 파일 또는 파일을 기반으로 실행할 Python 버전을 즉시 결정하는 특수 스크립트입니다 . 또한 명령을 사용하여 여러 Python 버전을 더 쉽게 다운로드하고 설치하는 프로세스를 만듭니다 .~/.pyenv/shimspythonpipPYENV_VERSION.python-version~/.pyenv/versionpyenvpyenv install

• pyenv-virtualenv를위한 플러그인 pyenv과 같은 저자 pyenv, 당신이 사용할 수 있도록 pyenv하고 virtualenv편리하게 동시에. 그러나 Python 3.3 이상 pyenv-virtualenv을 사용하는 python -m venv경우는 사용 가능한 경우 대신 virtualenv. 당신은 사용할 수 있습니다 virtualenv및 pyenv없이 함께 pyenv-virtualenv사용하면 편리한 기능을하지 않으려면.

• virtualenvwrapper에 대한 확장 집합입니다 virtualenv( docs 참조 ). 그것은 당신이 같은 명령을 제공합니다 mkvirtualenv, lssitepackages그리고 특히 workon다른 사이의 전환을위한 virtualenv디렉토리. 이 도구는 여러 virtualenv디렉터리 를 원하는 경우 특히 유용합니다 .

• pyenv-virtualenvwrapper를위한 플러그인 pyenv과 같은 저자 pyenv편리하게 통합 할 수있는, virtualenvwrapper에 pyenv.

• pipenv의 작성자 인 Kenneth Reitz requests가이 목록에있는 최신 프로젝트입니다. Pipfile, pip및 virtualenv명령 줄에서 하나의 명령으로 결합하는 것을 목표로 합니다. virtualenv디렉토리는 일반적으로에 배치됩니다 ~/.local/share/virtualenvs/XXX함께, XXX프로젝트 디렉토리의 경로의 해시되고. 이는 virtualenv디렉토리가 일반적으로 현재 작업 디렉토리에있는 와는 다릅니다 .

  Python 패키징 가이드 는pipenv Python 애플리케이션을 개발할 때 권장 합니다 (라이브러리와 반대). ( # 15 ) venv대신 지원할 계획이없는 것 같습니다 . 혼란스럽게도 명령 줄 옵션 은 디렉토리가 아니라 디렉토리를 참조합니다. 마찬가지로 환경 변수 는 디렉토리가 아닌 디렉토리 위치에 영향을줍니다 ( # 1919 ).virtualenv--venvvirtualenvvenvPIPENV_VENV_IN_PROJECTvirtualenvvenv

표준 라이브러리 :

• pyvenv는 Python 3에 포함 된 스크립트이지만 문제가있어 Python 3.6 에서는 더 이상 사용되지 않습니다 (혼란스러운 이름은 말할 것도 없습니다). Python 3.6 이상에서는 정확히 python3 -m venv.

• venv는 Python 3과 함께 제공되는 패키지로, 사용하여 실행할 수 있습니다 python3 -m venv(일부 배포판 python3-venv에서는 Ubuntu / Debian 과 같은 별도의 배포판 패키지로 분리되지만 ). 와 유사한 목적을 제공하고 virtualenv매우 유사한 방식으로 작동하지만 Python 바이너리를 복사 할 필요가 없습니다 (Windows 제외). 파이썬 2를 지원할 필요가 없다면 이것을 사용하십시오. 글을 쓰는 시점에서 파이썬 커뮤니티는 만족하는 것 같고 virtualenv나는 venv.

이러한 도구의 대부분은 서로를 보완합니다. 예를 들어, pipenv통합하고는 pip, virtualenv심지어 pyenv경우 원하는. 여기서 서로의 진정한 대안 인 유일한 도구는 venv및 virtualenv입니다.

초보자를위한 추천 :

이것은 초보자를위한 개인적 권장 사항입니다. Python 2 및 3과 다양한 상황에서 모두 작동하는 virtualenv및 pip도구를 배우는 것으로 시작하고 필요하기 시작하면 다른 도구를 선택합니다.

---

나는 virtualenvPython3.3 + 이후 의 사용을 피하고 대신 표준 제공 라이브러리를 사용합니다 venv. 새 가상 환경을 만들려면 다음을 입력합니다.

$ python3 -m venv <MYVENV>  

virtualenvPython 바이너리를 가상 환경의 bin 디렉터리에 복사하려고합니다. 그러나 해당 바이너리에 포함 된 라이브러리 파일 링크를 업데이트하지 않으므로 소스에서 Python을 상대 경로 이름이있는 비 시스템 디렉터리로 빌드하면 Python 바이너리가 중단됩니다. 이것이 배포 가능한 Python 사본을 만드는 방법이므로 큰 결함입니다. BTW를 사용하여 OS X에서 임베디드 라이브러리 파일 링크를 검사하려면 otool. 예를 들어 가상 환경 내에서 다음을 입력합니다.

$ otool -L bin/python
python:
    @executable_path/../Python (compatibility version 3.4.0, current version 3.4.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0)

결과적으로 나는 virtualenvwrapper및 pipenv. pyvenv더 이상 사용되지 않습니다. pyenv사용되는 곳에서 자주 사용되는 것 같지만 구축 된 일도 virtualenv한다고 생각하기 때문에 나는 그것을 멀리 할 것 입니다.venvpyenv

venv creates virtual environments in the shell that are fresh and sandboxed, with user-installable libraries, and it's multi-python safe. Fresh because virtual environments only start with the standard libraries that ship with python, you have to install any other libraries all over again with pip install while the virtual environment is active. Sandboxed because none of these new library installs are visible outside the virtual environment, so you can delete the whole environment and start again without worrying about impacting your base python install. User-installable libraries because the virtual environment's target folder is created without sudo in some directory you already own, so you won't need sudo permissions to install libraries into it. Finally it is multi-python safe, since when virtual environments activate, the shell only sees the python version (3.4, 3.5 etc.) that was used to build that virtual environment.

pyenv is similar to venv in that it lets you manage multiple python environments. However with pyenv you can't conveniently rollback library installs to some start state and you will likely need admin privileges at some point to update libraries. So I think it is also best to use venv.

In the last couple of years I have found many problems in build systems (emacs packages, python standalone application builders, installers...) that ultimately come down to issues with virtualenv. I think python will be a better platform when we eliminate this additional option and only use venv.

참고URL : https://stackoverflow.com/questions/41573587/what-is-the-difference-between-venv-pyvenv-pyenv-virtualenv-virtualenvwrappe