Неплохо ли иметь каталог virtualenv внутри моего репозитория git?

Ответ 1

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

Ответ 2

Хранение каталога virtualenv в git, как вы заметили, позволит вам развернуть все приложение, просто выполнив клон git (плюс установив и настроив Apache/mod_wsgi). Одна потенциально значимая проблема этого подхода заключается в том, что в Linux полный путь жестко запрограммирован в сценариях активации venv, django-admin.py, easy_install и pip. Это означает, что ваша 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 и повторно -r и pip install -r requirements.txt. Как уже отмечалось, это также уменьшает "спам".

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

Система может, например, с помощью модуля platform.

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

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

Ответ 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 на своем пути, прежде чем он будет найти один в текущем каталоге.

Ответ 7

Не стоит включать какой-либо компонент или параметр, зависящий от среды, в свои репозитории, поскольку одним из ключевых аспектов использования репо, возможно, является предоставление его другим разработчикам. Вот как я могу настроить свою среду разработки на ПК с Windows (скажем, Win10).

1. Откройте Pycharm и на первой странице выберите вариант проверки проекта из системы управления версиями (в моем случае я использую github)

2. В Pycharm перейдите к настройкам, выберите "Интерпретатор проекта" и выберите опцию добавления новой виртуальной среды, которую вы можете назвать "venv".

3. Выберите базовый интерпретатор Python, который находится по адресу C:\Users {user}\AppData\Local\Programs\Python\Python36 (убедитесь, что вы выбрали подходящую версию Python на основе того, что вы установили)

4. Обратите внимание, что Pycharm создаст новую виртуальную среду и скопирует двоичные файлы Python и необходимые библиотеки в вашу папку venv внутри папки вашего проекта.

5. Позвольте Pycharm завершить сканирование, чтобы восстановить/обновить каркас проекта

6. исключить папку venv из ваших взаимодействий с git (добавьте venv\в файл .gitignore в папке вашего проекта)

Бонус: если вы хотите, чтобы люди легко (ну, почти легко) устанавливали все библиотеки, в которых нуждается ваше программное обеспечение, вы можете использовать

pip freeze > requirements.txt

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

pip install -r requirements.txt 

Ответ 8

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

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

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