Плохо ли иметь каталог virtualenv в моем репозитории git?

Я делал то же самое, пока не начал использовать библиотеки, которые компилируются по-разному в зависимости от среды, такой как PyCrypto. Мой pycrypto mac не будет работать на Cygwin не будет работать на Ubuntu.

управление репозиторием становится сущим кошмаром.

в любом случае мне было проще управлять файлом pip freeze & a requirements, чем иметь все это в git. Это чище, так как вы можете избежать спама фиксации для тысяч файлов в качестве этих библиотек получить обновление...

хранение каталога virtualenv внутри git, как вы отметили, позволит вам развернуть все приложение, просто сделав клон git (плюс установка и настройка Apache/mod_wsgi). Одна потенциально важная проблема с этим подходом заключается в том, что в Linux полный путь получает жестко закодированный в активации venv, django-admin.py, easy_install и pip скрипты. Это означает, что ваш virtualenv не будет полностью работать, если вы хотите использовать другой путь, возможно, для запуска нескольких виртуальных хостов на одном и том же сервер. Я думаю, что веб-сайт может работать с неправильными путями в этих файлах, но у вас будут проблемы при следующей попытке запустить pip.

решение, уже приведенное, состоит в том, чтобы хранить достаточно информации в git, чтобы во время развертывания вы могли создать virtualenv и выполнить необходимые установки pip. Обычно люди бегут 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, так как вам придется вручную добавлять/удалять и фиксировать файлы, полученные в результате обновления. С требованиями.txt файл, вы просто изменить соответствующие строки в требованиях.txt и повторный запуск pip install -r requirements.txt. Как уже отмечалось, это также уменьшает "фиксацию спама".

Я думаю, что одна из основных проблем, которые возникают, заключается в том, что virtualenv может не использоваться другими людьми. Причина в том, что он всегда использует абсолютный путь. Так что если вы virtualenv был например в /home/lyle/myenv/ Он будет предполагать то же самое для всех других людей, использующих этот репозиторий (он должен быть точно таким же абсолютным путем). Вы не можете предполагать, что люди используют ту же структуру каталогов, что и вы.

лучшая практика заключается в том, что каждый создает свою собственную среду (будь то с или без virtualenv) и установка там библиотек. Это также делает код более удобным для использования на разных платформах (Linux/Windows/Mac), также потому, что virtualenv установлен по-разному в каждом из них.

Если вы знаете, на каких операционных системах будет работать ваше приложение, я бы создал один virtualenv для каждой системы и включил его в свой репозиторий. Затем я бы заставил свое приложение определить, в какой системе он работает, и использовать соответствующий virtualenv.

система может быть идентифицирована, например, с помощью платформа модуль.

на самом деле, это то, что я делаю с внутренним приложением, которое я написал, и к которому я могу быстро добавить новый virtualenv системы в случае необходимости. Таким образом, мне не нужно полагаться на то, что pip сможет успешно загрузить программное обеспечение, необходимое моему приложению. Я также не придется беспокоиться о компиляции, например,psycopg2 который я использую.

Если вы не знаете, в какой операционной системе может работать ваше приложение, вам, вероятно, лучше использовать pip freeze Как указано в другие ответы здесь.

Если вы просто настраиваете env разработки, а затем используете файл замораживания pip, caz, который делает git repo чистым.

затем, если выполняется развертывание производства, проверьте всю папку venv. Это сделает ваше развертывание более воспроизводимым, не нуждается в этих пакетах libxxx-dev и избежать проблем с интернетом.

Итак, есть два РЕПО. Один для основного исходного кода, который включает в себя требования.формат txt. И env repo, который содержит всю папку venv.

Я использую то, что в основном ответ Дэвида Сикмиллера С немного большей автоматизацией. Я создаю (не исполняемый) файл на верхнем уровне моего проекта под названием 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"

(согласно ответу Дэвида, это предполагает, что вы делаете pip freeze > requirements.txt чтобы сохранить ваш список требований до дата.)

это может быть получено из любого текущего рабочего каталога и будет правильно активировать, сначала настроив виртуальную среду, если необходимый. Мой тестовый скрипт верхнего уровня обычно имеет код вдоль этих строк, чтобы его можно было запустить без необходимости активации разработчиком:

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