내 git 저장소에 virtualenv 디렉토리를 두는 것이 좋지 않습니까?

내 git 저장소에 virtualenv 디렉토리를 두는 것이 좋지 않습니까?

---

Django 웹 응용 프로그램의 virtualenv를 응용 프로그램의 git 저장소 내부에 넣을 생각입니다. 배포를 간단하고 쉽게 유지하는 쉬운 방법 인 것 같습니다. 내가 이것을해서는 안되는 이유가 있습니까?

---

내가 사용하는 pip freeze난에 필요한 패키지를 얻기 위해 requirements.txt파일을 내 저장소에 저를 추가 할 수 있습니다. 전체 virtualenv를 저장하려는 이유를 생각했지만 시도 할 수 없었습니다.

---

git에 virtualenv 디렉토리를 저장하면 git clone (Apache / mod_wsgi 설치 및 구성)을 수행하여 전체 앱을 배포 할 수 있습니다. 이 접근 방식에서 잠재적으로 중요한 문제 중 하나는 Linux에서 전체 경로가 venv의 activate, django-admin.py, easy_install 및 pip 스크립트에 하드 코딩된다는 것입니다. 즉, 동일한 경로에서 여러 가상 호스트를 실행하기 위해 다른 경로를 사용하려는 경우 virtualenv가 완전히 작동하지 않습니다. 웹 사이트가 실제로 해당 파일에서 잘못된 경로로 작동 할 수 있다고 생각하지만 다음에 pip를 실행하려고하면 문제가 발생합니다.

이미 제공된 해결책은 배포 중에 virtualenv를 생성하고 필요한 pip 설치를 수행 할 수 있도록 충분한 정보를 git에 저장하는 것입니다. 일반적으로 사람들 pip freeze은 목록을 가져 와서 requirements.txt라는 파일에 저장합니다. 로로드 할 수 있습니다 pip install -r requirements.txt. RyanBrady는 이미 deploy 문을 한 줄로 묶는 방법을 보여주었습니다.

# before 15.1.0
virtualenv --no-site-packages --distribute .env &&\
    source .env/bin/activate &&\
    pip install -r requirements.txt

# after deprecation of some arguments in 15.1.0
virtualenv .env && source .env/bin/activate && pip install -r requirements.txt

개인적으로, 나는 이것을 git clone 또는 git pull을 한 후에 실행하는 쉘 스크립트에 넣었습니다.

virtualenv 디렉토리를 저장하면 업그레이드로 인한 파일을 수동으로 추가 / 제거 및 커밋해야하므로 pip 업그레이드를 처리하기가 약간 까다로워집니다. requirements.txt 파일을 사용하면 requirements.txt에서 해당 줄을 변경하고 다시 실행하면 pip install -r requirements.txt됩니다. 이미 언급했듯이 "커밋 스팸"도 줄입니다.

---

PyCrypto와 같은 환경에 따라 다르게 컴파일 된 라이브러리를 사용하기 시작할 때까지 동일한 작업을 수행했습니다. Cygwin에서는 PyCrypto mac이 작동하지 않으며 Ubuntu에서는 작동하지 않습니다.

저장소를 관리하는 것은 완전히 악몽이됩니다.

어느 쪽이든 pip 동결 및 요구 사항 파일을 모두 git에 넣는 것보다 관리하기가 쉽다는 것을 알았습니다. 라이브러리가 업데이트 될 때 수천 개의 파일에 대한 커밋 스팸을 피할 수 있기 때문에 더 깨끗합니다 ...

---

발생하는 주요 문제 중 하나는 다른 사람들이 virtualenv를 사용할 수 없다는 것입니다. 이유는 항상 절대 경로를 사용하기 때문입니다. 따라서 예를 들어 virtualenv 인 /home/lyle/myenv/경우이 저장소를 사용하는 다른 모든 사람들에게 동일하다고 가정합니다 (정확히 동일한 절대 경로 여야 함). 당신과 같은 디렉토리 구조를 사용하는 사람들을 추정 할 수 없습니다.

더 좋은 방법은 모든 사람이 자신의 환경을 설정하고 (virtuenv가 있거나없는 환경) 라이브러리를 설치하는 것입니다. 또한 virtualenv가 플랫폼마다 다르게 설치되어 있기 때문에 다른 플랫폼 (Linux / Windows / Mac)에서 코드를 더 유용하게 사용할 수 있습니다.

---

응용 프로그램이 실행될 운영 체제를 알고 있다면 각 시스템마다 하나의 virtualenv를 만들어 내 저장소에 포함시킵니다. 그런 다음 응용 프로그램에서 실행중인 시스템을 감지하고 해당 virtualenv를 사용합니다.

시스템은 예를 들어 플랫폼 모듈을 사용하여 식별 될 수 있습니다 .

실제로 이것은 내가 작성한 사내 응용 프로그램으로 수행하는 것이며 필요한 경우 새 시스템의 virtualenv를 신속하게 추가 할 수 있습니다. 이렇게하면 응용 프로그램에 필요한 소프트웨어를 pip에서 성공적으로 다운로드 할 수 있습니다. 또한 사용하는 psycopg2의 컴파일에 대해 걱정할 필요가 없습니다 .

응용 프로그램이 실행될 운영 체제를 모르는 경우 pip freeze다른 답변에서 제안한대로 사용 하는 것이 좋습니다.

---

나는 기본적으로 David Sickmiller의 대답 을 약간 더 자동화하여 사용합니다. activate다음 내용으로 이름이 지정된 프로젝트의 최상위 레벨에 (실행 파일이 아닌) 파일을 만듭니다 .

[ -n "$BASH_SOURCE" ] \
    || { echo 1>&2 "source (.) this with Bash."; exit 2; }
(
    cd "$(dirname "$BASH_SOURCE")"
    [ -d .build/virtualenv ] || {
        virtualenv .build/virtualenv
        . .build/virtualenv/bin/activate
        pip install -r requirements.txt
    }
)
. "$(dirname "$BASH_SOURCE")/.build/virtualenv/bin/activate"

(David의 답변에 따르면 pip freeze > requirements.txt요구 사항 목록을 최신 상태로 유지하기 위해 노력 하고 있다고 가정합니다 .)

위의 일반적인 아이디어를 제공합니다; 실제 활성화 스크립트 ( 문서 내가 일반적으로 사용이 제공하는 좀 더 복잡한 것을) -q사용 (자동) 옵션을 python때 python3등을 사용할 수 없습니다

그러면 현재 작업중인 디렉토리에서 소스를 얻을 수 있으며 필요한 경우 먼저 가상 환경을 설정하여 올바르게 활성화됩니다. 내 최상위 테스트 스크립트에는 일반적으로 다음 줄에 코드가 있으므로 개발자가 먼저 활성화하지 않고도 실행할 수 있습니다.

cd "$(dirname "$0")"
[[ $VIRTUAL_ENV = $(pwd -P) ]] || . ./activate

소싱 은 여기서 중요 ./activate하지 않습니다 activate. 후자는 activate현재 디렉토리에서 경로를 찾기 전에 경로에서 다른 것을 찾을 수 있기 때문 입니다.

---

개발 환경을 설정 한 경우 pip freeze 파일 인 caz를 사용하여 git repo를 깨끗하게하십시오.

그런 다음 프로덕션 배포를 수행하는 경우 전체 venv 폴더를 체크인하십시오. 그러면 배포를보다 재현 가능하게하고 libxxx-dev 패키지가 필요하지 않으며 인터넷 문제를 피할 수 있습니다.

따라서 두 개의 저장소가 있습니다. requirements.txt가 포함 된 기본 소스 코드 용 코드입니다. 그리고 전체 venv 폴더를 포함하는 env repo.

참고 URL : https://stackoverflow.com/questions/6590688/is-it-bad-to-have-my-virtualenv-directory-inside-my-git-repository