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

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

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

В любом случае мне было проще управлять замораживанием и файлом требований, чем все это в 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 уже показал, как вы можете вставлять операторы развертывания в одну строку:

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

Лично я просто помещаю их в оболочку script, которую я запускаю после выполнения git clone или git pull.

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

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

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

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

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

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

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

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

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

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