Каковы преимущества pip и virtualenv?
Итак, все говорят мне использовать pip и virtualenv, но никто не может объясните мне, чем это лучше, чем мой нынешний подход. Главная причина для людей, использующих pip и virtualenv, похоже, что все остальные используют его ...
Я уверен, что есть очень веские причины использовать PIP и virtualenv, но я не смог найти их с помощью Google. Я надеюсь, что кто-то из Сообщество stackoverflow сможет объяснить мне их.
Вот как я в настоящее время организовываю свои проекты Django:
site/src/ : contains all python-only dependencies of my project
site/lib/ : contains symlinks to the python packages
site/[projectname]/ : contains all my project specific code
Вся папка сайта проверяется в моем репозитории (да, включая все зависимости только для python, такие как сам django) .
Все зависимости, не относящиеся только к Python (PIL, psycopg2, ...), задокументированы в README и установлены на системном уровне (apt-get install ....)
Например, допустим, я иметь название проекта "projectfoo", которое зависит от django-1.2.3, pygeoip-0.1.3 и psycopg2 У меня будет:
/usr/lib/python2.5/site-packages/psycopg2
~/projects/foo/site : checkout of my repository
~/projects/foo/site/src/django-1.2.3
~/projects/foo/site/src/pygeoip-0.1.3
~/projects/foo/site/lib/django -> symlink to ../src/django-1.2.3/django
~/projects/foo/site/lib/pygeoip -> symlink to ../src/pygeoip-0.1.3/pygeoip
~/projects/foo/site/projectfoo/
Как это соотносится с PIP / virtualenv на практике?
Развертывание проекта с моим текущим подходом :
svn checkout https://myserver.com/svn/projectfoo/tags/1.0.0STABLE/site
Развертывание с PIP / virtualenv :
wget https://myserver.com/svn/projectfoo/tags/1.0.0STABLE/projectfoo-requirements.txt
pip install -U -E projectfoo-venv -r projectfoo-requirements.txt
Работа над проектом с моим текущим подходом :
cd ~/projects/foo/site/projectfoo
export PYTHONPATH=.:..:../lib
./manage.py runserver 0:8000
Работа над проектом с PIP / virtualenv :
workon projectfoo
cd path/to/project
./manage.py runserver 0:8000
Работа с зависимостями, не связанными только с Python :
зависимости, не относящиеся только к Python, будут обрабатываться таким же образом, я не могу
собираюсь использовать опцию - no-site-packages virtualenv и установить компилятор
и все зависимости сборки на моих серверах, я не думаю, что кто-то на самом деле
все равно делаю это.
Обновление зависимости только для python с моим текущим подходом :
Я проверяю / распаковываю новую версию в src, удаляю старую из src, обновляю
символическая ссылка в библиотеке и фиксации. Теперь все, кто работает над проектом, получат обновления по адресу
их следующий svn up или git pull . Некрасиво то, что старые
папка в src останется, если она содержит какой-то файл pyc, это может легко
можно избежать, удалив все pyc перед обновлением вашей локальной копии.
Обновление зависимости только для Python с помощью PIP / virtualenv :
Вы фиксируете новую версию файла требований, надеюсь, все, кто работает над
project замечает новую версию, когда обновляет свою локальную копию, а затем
запустите pip install -E projectfoo-venv -r requirements.txt .
Правка : я удаляю использование -U с помощью pip, это не требуется с pip 8.2
Изменить : Единственное преимущество pip / virtualenv над моим текущим подходом, кажется, когда вы работаете в разных проектах, требующих разных версий Python. Но по моему опыту, когда вам нужны разные версии python, вы также нужны разные версии других системных библиотек (PIL, psycopg2, ...) и virtualenv в этом не помогает (кроме тех случаев, когда вы достаточно сумасшедшие, чтобы используйте параметр --no-site-package, и даже в этом случае он неполный). В единственное решение, которое я могу придумать в этой ситуации, - использовать разные виртуальные машины.
Так что же мне не хватает? Может ли кто-нибудь указать мне на случай использования, когда PIP или virtualenv было бы лучше, чем то, что я делаю?