Итак, все говорят мне использовать 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 и установлены в системе.level (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
Работа с non-python-only зависимости :
зависимости не только для Python будут обрабатываться таким же образом, я не собираюсь использовать опцию virtualenv --no-site-packages, установить компилятор и всю сборкузависимости от моих серверов, я не думаю, что кто-то на самом деле делает это в любом случае.
Обновление зависимости только для Python с моим текущим подходом :
Я извлекаю / разархивируюновая версия в src, удалите старую из src, обновите символическую ссылку в lib и подтвердите.Теперь все остальные, работающие над проектом, получат обновление в следующий svn up или git pull.Одна вещь, которая не очень приятна, это то, что старая папка в src останется, если в ней будет какой-то файл pyc, этого можно легко избежать, удалив все pyc перед обновлением локальной копии.
Обновлениезависимость только для Python с PIP / virtualenv :
Вы фиксируете новую версию файла требований, надеюсь, все, кто работает над проектом, заметят новую версию, когда обновят свою локальную копию, а затем запустят pip install -E projectfoo-venv -r requirements.txt.
Редактировать : я убрал использование -U для пипса, это не нужно для пипса 8.2
Редактировать : единственное преимущество в пипсе/ virtualenv по сравнению с моим текущим подходом, кажется, когда вы работаете над различными проектами, требующими разные версии Python.Но по моему опыту, когда вам нужны разные версии python, вам также нужны разные версии других системных библиотек (PIL, psycopg2, ...), и virtualenv не поможет с этим (кроме случаев, когда вы достаточно сумасшедший, чтобы использовать -опция no-site-package, и даже тогда она неполная).Единственное решение, которое я могу придумать для этой ситуации, - это использование разных виртуальных машин.
Так чего мне не хватает?Может кто-нибудь указать мне случай использования, где PIP или virtualenv были бы лучше, чем то, что я делаю?