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

Question

Я думаю о том, чтобы поместить virtualenv для веб-приложения Django, которое я создаю, в свой git-репозиторий для приложения.Кажется, что простой способ сделать развертывание простым и легким.Есть ли причина, по которой я не должен этого делать?

Answer 1

Я использую pip freeze, чтобы получить нужные мне пакеты в файл requirements.txt и добавить его в свой репозиторий. Я пытался придумать способ, почему вы захотите сохранить весь virtualenv, но не смог.

Answer 2

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

Решение, которое уже дано, состоит в том, чтобы хранить достаточно информации в git, чтобы во время развертывания вы могли создать virtualenv и выполнить необходимые установки pip. Как правило, люди запускают pip freeze, чтобы получить список, а затем сохранить его в файле с именем needs.txt. Может быть загружен с pip install -r requirements.txt. RyanBrady уже показал, как можно выстроить операторы развертывания в одну строку:

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

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

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

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

Answer 6

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

Вышесказанное дает общую идею; фактический сценарий активации ( документация ), который я обычно использую, немного сложнее, предлагает параметр -q (тихий), использующий python, когда python3 нет доступны и т. д.

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

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

Sourcing ./activate, а не activate, важен здесь, потому что последний найдет любой другой activate в вашем пути, прежде чем он найдет тот в текущем каталоге.

Answer 7

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

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

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