Django: Какой подход лучше [virtualenv + pip] против [перенос пакетов вручную в svn]?

Question

У меня есть проект django, в котором используется множество сторонних приложений, поэтому я решил выбрать один из двух подходов к управлению моей ситуацией:

1. Я могу использовать [virtualenv + pip] вместе с pip freeze в качестве файла требований для управления зависимостями моего проекта.

   Мне не нужно беспокоиться о приложениях, но я не могу передать это с моим кодом в svn.

2. У меня может быть папка lib в моей структуре svn, и мои приложения находятся там и добавляют ее в sys.path

Таким образом, мои зависимости могут быть привязаны к SVN, но я должен управлять sys.path

Куда мне идти?

Каковы плюсы и минусы каждого подхода?

Обновление:

Method1 Недостаток: Сложно работать с appengine.

Answer 1

Так что это то, что я сейчас использую.

У всех проектов будет корневая директория virtualenv.Мы называем это как .env и игнорируем в vcs.Первое, что сделал dev, когда начал заниматься разработкой, - это инициализировал virtualenv и установил все требования, указанные в файле needs.txt.Я предпочитаю иметь virtualenv внутри dir проекта, чтобы он был очевиден для разработчика, а не в каком-то другом месте, например $HOME/.virtualenv, а затем делать source $HOME/virtualenv/project_name/bin/activate для активации среды.Вместо этого разработчик взаимодействует с virtualenv, вызывая исполняемый файл env непосредственно из корня проекта, например: -

.env/bin/python
.env/bin/python manage.py runserver

Для развертывания у нас есть сценарий Fabric, который сначала экспортирует каталог нашего проекта вместе с каталогом .env.в tarball, затем скопируйте tarball на работающий сервер, распакуйте его каталог развертывания и выполните некоторые другие задачи, такие как перезапуск сервера и т. д. Когда мы распаковываем tarball на работающем сервере, сценарий фабрики обязательно запускает virtualenv, чтобы всепуть Шебанга в .env/bin исправлен.Это означает, что нам не нужно переустанавливать зависимости снова на работающем сервере.Рабочий процесс фабрики для развертывания будет выглядеть следующим образом: -

fab create_release:1.1 # create release-1.1.tar.gz
fab deploy:1.1 # copy release-1.1.tar.gz to live server and do the deployment tasks
fab deploy:1.1,reset_env=1 # same as above but recreate virtualenv and re-install all dependencies
fab deploy:1.1,update_pkg=1 # only reinstall deps but do not destroy previous virtualenv like above

Мы также не устанавливаем src проекта в virtualenv с помощью setup.py, а вместо этого добавляем путь к нему в sys.path.Поэтому при развертывании в mod_wsgi мы должны указать 2 пути в нашей конфигурации vhost для mod_wsgi, что-то вроде: -

WSGIDaemonProcess project1 user=joe group=joe processes=1 threads=25 python-path=/path/to/project1/.env/lib/python2.6/site-packages:/path/to/project1/src

Короче:

1. Мы по-прежнему используем pip + virtualenvдля управления зависимостями.
2. Нам не нужно переустанавливать требования при развертывании.
3. Нам нужно немного поддерживать путь в sys.path.

Answer 2

Virtualenv и pip отлично подходят для работы над несколькими проектами django на одной машине. Однако, если у вас есть только один проект, который вы редактируете, не обязательно использовать virtualenv.

Answer 3

Этот вопрос до сих пор оставался без ответа (по крайней мере, для меня).В последнее время обсуждается это: -

https://plus.google.com/u/0/104537541227697934010/posts/a4kJ9e1UUqE

Ян Биккинг сказал об этом в комментарии: -

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

http://tarekziade.wordpress.com/2012/02/10/defining-a-wsgi-app-deployment-standard/

ПервыйПодход кажется наиболее распространенным среди разработчиков Python.Когда я впервые начал заниматься разработкой в ​​Django, это было немного странно, поскольку при работе с PHP довольно часто проверять сторонние библиотеки lib в репозитории проекта, но, как сказал Ян Биккинг в связанном посте, развертывание в стиле PHP исключает такие вещипортативная библиотека.Вы не хотите упаковывать такие вещи, как mysqldb или PIL, в ваш проект, который лучше обрабатывать такими инструментами, как Pip или распространять.