所以每个人都告诉我使用pip和virtualenv，但没有人能够 解释一下它比我目前的做法更好。主要原因 对于人们使用pip和virtualenv似乎是其他人都在使用它...
我确信有很好的理由使用PIP和virtualenv，但我没有 能够通过谷歌找到它们。我希望有人来自 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-only依赖项（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-only依赖项将以相同的方式处理，我没有办法
将使用virtualenv的--no-site-packages选项并安装编译器
以及我服务器上的所有构建依赖项，我认为实际上并不是任何人
无论如何要这样做。
使用我当前的方法升级仅限python的依赖：
我在src中签出/解压缩新版本，从src中删除旧版本，更新
lib和commit中的符号链接。现在，参与该项目的所有其他人都将获得更新
他们的下一个svn up或git pull。一件不太好的事情是旧的
src中的文件夹将保留，如果它包含一些pyc文件，这很容易
通过在更新本地副本之前删除所有pyc来避免。
使用PIP / virtualenv 升级仅限python的依赖项：
你提交了一个新版本的需求文件，希望每个人都在工作
项目在更新本地副本时会注意到新版本
运行pip install -E projectfoo-venv -r requirements.txt。
编辑：我删除了使用-ip和pip，pip 8.2不需要这样做
编辑：pip / virtualenv相对于我当前方法的唯一优势似乎是当您处理需要不同版本python的不同项目时。但 根据我的经验，当你需要不同版本的python的时候 需要不同版本的其他系统库（PIL，psycopg2，...） 而且virtualenv没有帮助（除非你疯了 使用--no-site-package选项，即使这样也不完整）。该 我能想到的唯一解决方案是使用不同的虚拟机。
所以我错过了什么？有人可以指向PIP或virtualenv的用例 会比我正在做的更好吗？
答案 0 :(得分：14)
答案 1 :(得分：7)
“所有非python-only依赖项（PIL，psycopg2，...）都记录在README中并安装在系统级别（apt-get install ....）” < / p>
然后，您不能为不同的项目提供不同的依赖关系，而不是不同项目的这些依赖关系的不同版本。
其中一个影响是您的本地安装不能准确反映生产机器，因此您可能在重现生产错误方面遇到问题。例如。
如果您安装需要一个版本的系统工具，您将被迫在任何地方使用相同的版本，这可能会破坏您的项目。
此外，取消删除模块需要在系统python级别上完成。 Virtualenv意味着您可以设置python安装来测试，而不会污染系统安装。
我绝对建议为你的项目使用一个单独的python，并使用一些东西甚至将Python与项目隔离开来，比如virtualenv或zc.buildout。
PIP只是一种安装模块的简单方法，也可以帮助您卸载它们。
“我无法使用virtualenv的--no-site-packages选项并在我的服务器上安装编译器和所有构建依赖项，我认为没有人真正在做无论如何。“
不，我使用的是zc.buildout，但它的功能大致相同，但工作量较少。 ;）
答案 2 :(得分：3)
我按照你建议的方法，没有pip / virtualenv用于我的常规项目。 这允许我将包放在特定的目录中。
+ext
|
|------python packages
+source
|
|------ project code and packages
通常在启动脚本中我更新PYTHONPATH
export PYTHONPATH="";
export PYTHONPATH="${PYTHONPATH}:${workingdir}/path/to/ext";
这样可以保持项目和依赖项自包含。我回答，你的想法在这里。
然而，当我
时，我发现使用了virtualenvsomething new。 two different versions of package并比较它们时更好。different related packages that can be used across projects。Ex：文档：我安装的一些关键软件包包括sphinx，pygraphwiz，nterworkX和一些其他可视化软件包。我在项目中使用它，并使其不受系统级安装的影响，以保持其不受污染。
我也希望你结账：蛋黄。我觉得pip / virtualenv的组合很好。
您可以列出包
yolk -l
Jinja2 - 2.5.5 - active
Markdown - 2.0.3 - active
Pycco - 0.1.2 - active
......
查看pypi更新。
yolk --show-updates
Pycco 0.1.2 (0.2.0)
Sphinx 1.0.4 (1.0.5)
pip 0.8.1 (0.8.2)
答案 3 :(得分：2)
据你说：
wget https://myserver.com/svn/projectfoo/tags/1.0.0STABLE/projectfoo-requirements.txt pip install -U -E projectfoo-venv -r projectfoo-requirements.txt
我的所作所为：我还“冻结”了套餐，但是我使用pip和virtualenv执行此操作并检查整个项目;包括Python包。所以我的部署与你的完全一样：
svn checkout https://myserver.com/svn/projectfoo/tags/1.0.0STABLE/site
据你说：
workon projectfoo cd path/to/project ./manage.py runserver 0:8000
我的所作所为：像这样添加postactivate hook：
$ cat bin/postactivate
cd $VIRTUAL_ENV
./manage.py runserver 0:8000
$
现在，要改变项目：
workon projectfoo