そのため、誰もが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
サイトフォルダ全体が私のリポジトリにチェックインされます（はい、django自体などのすべてのPythonのみの依存関係を含みます）。
Pythonのみ以外のすべての依存関係（PIL、psycopg2、...）は、READMEに文書化されており、システムレベルでインストールされます（apt-get install ....）
たとえば、django-1.2.3、pygeoip-0.1.3、およびpsycopg2に依存するプロジェクト名「projectfoo」があるとします。
/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から古いバージョンを削除し、libでシンボリックリンクを更新してコミットします。これで、プロジェクトに取り組んでいる他のすべての人が、次のsvn upまたはで更新を取得しgit pullます。良くないことの1つは、srcに古いフォルダーが含まれている場合にそのフォルダーが残ることです。これは、ローカルコピーを更新する前にすべてのpycを削除することで簡単に回避できます。
PIP / virtualenvを使用したPythonのみの依存関係のアップグレード：
要件ファイルの新しいバージョンをコミットします。プロジェクトで作業しているすべての人が、ローカルコピーを更新して実行すると、新しいバージョンに気付くことができれば幸いですpip install -E projectfoo-venv -r requirements.txt。
編集：pipでの-Uの使用を削除しました。これはpip8.2では必要ありません。
編集：私の現在のアプローチに対するpip / virtualenvの唯一の利点は、異なるバージョンのpythonを必要とする異なるプロジェクトで作業する場合にあるようです。しかし、私の経験では、Pythonの異なるバージョンが必要な場合、他のシステムライブラリ（PIL、psycopg2、...）の異なるバージョンも必要であり、virtualenvはそれを助けません（あなたが-を使用するのに十分狂っている場合を除いて） no-site-packageオプション、それでも不完全です）。その状況で私が考えることができる唯一の解決策は、さまざまな仮想マシンを使用することです。
だから私は何が欠けていますか？PIPまたはvirtualenvが私がやっていることよりも優れているユースケースを誰かが私に指摘できますか？