virtualenv에서 사용자 지정 코드는 어디에 있습니까?


107

사용할 때 어떤 종류의 디렉토리 구조를 따라야 virtualenv합니까? 예를 들어 WSGI 응용 프로그램을 빌드하고 가상 환경을 만든 경우 다음 foobar과 같은 디렉터리 구조로 시작합니다.

/foobar
  /bin
    {activate, activate.py, easy_install, python}
  /include
    {python2.6/...}
  /lib
    {python2.6/...}

이 환경이 만들어지면 자신의 위치는 어디에 있습니까?

  • 파이썬 파일?
  • 정적 파일 (이미지 / 기타)?
  • 온라인에서 구할 수 있지만 치즈 상점에서 찾을 수없는 것과 같은 "맞춤형"패키지?

virtualenv디렉토리 와 관련하여 ?

( virtualenv 디렉토리 자체가 어디로 가야 하는지 이미 알고 있다고 가정합니다 .)


8
@jkp : 동의하지 않습니다. Python 애플리케이션을 레이아웃하는 방법은 개발 목적으로 virtualenv 내에서 해당 애플리케이션을 찾는 방법과는 다릅니다. 관련이 있지만 동일하지는 않습니다. 중복으로 닫지 마십시오.
jcdyer

답변:


90

virtualenv애플리케이션 인스턴스가 아닌 Python 인터프리터 인스턴스를 제공합니다. 일반적으로 시스템의 기본 Python이 포함 된 디렉터리 내에 애플리케이션 파일을 생성하지 않습니다. 마찬가지로 virtualenv 디렉터리 내에서 애플리케이션을 찾을 필요가 없습니다.

예를 들어 동일한 virtualenv를 사용하는 여러 애플리케이션이있는 프로젝트가있을 수 있습니다. 또는 나중에 시스템 Python과 함께 배포 될 virtualenv로 애플리케이션을 테스트 할 수 있습니다. 또는 앱 디렉터리 자체 내에 virtualenv 디렉터리가있는 것이 합리적 일 수있는 독립 실행 형 앱을 패키징 할 수 있습니다.

따라서 일반적으로 질문에 대한 정답은 하나도 없다고 생각합니다. 그리고 좋은 점은 virtualenv다양한 사용 사례를 지원한다는 것입니다. 올바른 방법이있을 필요는 없습니다.


8
동의합니다. 나는 내가하는 모든 일에 virtualenv를 사용하고, virtualenv 디렉토리에 파일을 두지 않는다. Virtualenv는 프로젝트 구조에 영향을 미치지 않습니다. virtualenv를 활성화 (또는 bin / python 사용)하고 파일이있는 곳이면 어디에서나 작업하십시오.
Carl Meyer

나도 전심으로 동의합니다. 유일한 시간 나는 지금까지 내 VIRTUALENV (I 사용 내부의 파일을 터치 virtualenvwrapper내가 편집하고자 할 때)입니다 postactivatepostdeactivate후크.
Thane Brimhall 2013 년

이 질문의 다른 답변에서 볼 수 있듯이 트레이드 오프를 포함하여 다양한 옵션의 구체적이고 실제적인 예를 통해 질문을 더 잘 처리 할 수 ​​있습니다.
andyfeller

2
프로젝트를 virtualenv디렉토리와 별도로 유지하는 것이 더 깨끗 하지만 virtualenv시스템 파이썬 과 비교 하는 것은 도움이되지 않습니다. 왜냐하면 그 목적은 virtualenv깨진 종속성을 수정하고 프로젝트를 분리하여 다른 패키지 버전과 심지어 파이썬 버전을 사용할 수 있기 때문입니다. -python3). 앱이 a를 공유하도록 허용하면 마치 시스템 파이썬 인 것처럼 virtualenv사용 virtualenv되므로 앱이 virtualenv가 해결하도록 설계된 동일한 문제에 취약하게됩니다. There should be one obvious way to do it; 논리적으로 그것은 1 : 1이어야합니다
Davos

@Ned : 몇 가지 모범 사례를 얻으려고했지만 여전히 명확하지 않습니다. 각각 자체 virtualenv가있는 수십 개의 프로젝트가있는 경우 어떤 프로젝트가 어떤 virtualenv와 함께 사용되는지 어떻게 추적합니까? 사용하는 virtualenv의 이름으로 각 폴더의 루트에 작은 셸 스크립트를 추가 하시겠습니까?
ccpizza

57

자주 프로젝트가 몇 개만있는 경우 각 프로젝트에 대해 새 virtualenv를 만들고 패키지를 바로 안에 넣는 것을 막을 수는 없습니다.

/foobar
  /bin
    {activate, activate.py, easy_install, python}
  /include
    {python2.6/...}
  /lib
    {python2.6/...}
  /mypackage1
    __init__.py
  /mypackage2
    __init__.py

이 접근 방식의 장점은 항상 내부 프로젝트에 속하는 활성화 스크립트를 찾을 수 있다는 것입니다.

$ cd /foobar
$ source bin/activate
$ python 
>>> import mypackage1
>>>

좀 더 체계화하기로 결정했다면 모든 가상 환경을 하나의 폴더에 넣고 작업중인 프로젝트의 이름을 따서 각각의 이름을 지정해야합니다.

  /virtualenvs
    /foobar
      /bin
        {activate, activate.py, easy_install, python}
      /include
        {python2.6/...}
      /lib
        {python2.6/...}
  /foobar
    /mypackage1
      __init__.py
    /mypackage2
      __init__.py

이렇게하면 문제가 발생할 때 항상 새로운 virtualenv로 다시 시작할 수 있으며 프로젝트 파일은 안전하게 유지됩니다.

또 다른 장점은 여러 프로젝트에서 동일한 virtualenv를 사용할 수 있으므로 종속성이 많은 경우 동일한 설치를 반복 할 필요가 없다는 것입니다.

$ cd /foobar
$ source ../virtualenvs/foobar/bin/activate
$ python 
>>> import mypackage2
>>>

정기적으로 virtualenv를 설정하고 해체해야하는 사용자에게는 virtualenvwrapper를 살펴 보는 것이 좋습니다.

http://pypi.python.org/pypi/virtualenvwrapper

virtualenvwrapper를 사용하면 다음을 수행 할 수 있습니다.

* create and delete virtual environments

* organize virtual environments in a central place

* easily switch between environments

"foo"및 "bar"프로젝트에서 작업 할 때 가상 환경이 어디에 있는지 더 이상 걱정할 필요가 없습니다.

  /foo
    /mypackage1
      __init__.py
  /bar
    /mypackage2
      __init__.py

다음은 "foo"프로젝트 작업을 시작하는 방법입니다.

$ cd foo
$ workon
bar
foo
$ workon foo
(foo)$ python
>>> import mypackage1
>>>

그런 다음 프로젝트 "바"로 전환하는 것은 다음과 같이 간단합니다.

$ cd ../bar
$ workon bar
(bar)$ python
>>> import mypackage2
>>>

꽤 깔끔하지 않나요?


나는 강력하게 사용하는 방법에 대한이 답변에 동의 virtualenvwrapper. 가상 환경을 깔끔하게 추상화하면서 모든 이점을 제공합니다.
Thane Brimhall 2013 년

5
그러나 가상 환경에 코드를 넣는 것에 대해 강력하게 동의하지 않습니다 . 파일 시스템의 프로젝트 "근처"를 원하면 venv/프로젝트의 BASE_DIR.
롭 그랜트

30

virtualenv는 재배치 할 수 없기 때문에 프로젝트 파일을 virtualenv 디렉토리에 배치하는 것은 좋지 않습니다. virtualenv 자체는 프로젝트의 일부가 아닌 생성 된 개발 / 배포 아티팩트 (.pyc 파일과 유사)입니다. 쉽게 날려 버리고 언제든지 다시 만들거나 새 배포 호스트에서 새 호스트를 만드는 등의 작업이 쉬워야합니다.

실제로 많은 사람들이 virtualenvwrapper를 사용 합니다. 이것은 당신의 인식에서 실제 virtualenvs를 거의 완전히 제거하고 기본적으로 $ HOME / .virtualenvs에 나란히 배치합니다.


특히 배포를 테스트하고 필요하지 않은 요구 사항 패키지를 없애기 위해 날려 버리고 다시 만들기가 쉬워야한다는 점을 지적하는 것이 나쁜 습관이라는 데 완전히 동의합니다. 그냥 예를 들어, 사용 재배치하는 VIRTUALENV를 추가 할 수 있습니다 원하는 virtualenv --relocatable myvenv참조 stackoverflow.com/a/6628642/1335793을 당신은 당신이 생각해야 의미하지 않는다 수해서.
Davos

2

프로젝트에를 제공하면 setup.pypip는 버전 제어에서 직접 가져올 수 있습니다.

다음과 같이하십시오.

$ virtualenv --no-site-packages myproject
$ . myproject/bin/activate
$ easy_install pip
$ pip install -e hg+http://bitbucket.org/owner/myproject#egg=proj

-e에서 프로젝트를 넣어 것입니다 myproject/src,하지만에 연결 myproject/lib/pythonX.X/site-packages/하나가 바로 지역에서 가져 모듈에 집어 얻을 것이다 변경 한 있도록 site-packages. 그만큼#egg비트는 당신을 위해 만들어 계란 패키지에 부여 할 이름을 무엇 핍을 알려줍니다.

을 사용하지 않는 경우 옵션 --no-site-packages을 사용하여 pip가 virtualenv에 설치되도록 지정해야합니다.-E

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.