pip和virtualenv有什么好处？
所以每个人都告诉我使用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依赖项(PIL、psycopg2等)都记录在自述文件中，并安装在系统级(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的依赖关系也会以同样的方式处理，我不可能使用virtualenv的--no-site-packages选项在我的服务器上安装一个编译器和所有的构建依赖关系，我不认为任何人都会这样做。
使用我当前的方法升级一个纯python依赖项
我签出/解压缩src中的新版本，从src中删除旧版本，更新lib中的符号链接并提交。现在，在这个项目中工作的其他每个人都将在他们的下一个svn up或git pull上获得更新。一件不好的事情是，如果src中包含一些pyc文件，src中的旧文件夹将保留下来，这可以通过在更新本地副本之前删除所有pyc来轻松避免。
使用PIP/virtualenv升级仅python依赖项
你提交了一个新版本的需求文件，希望在项目中工作的每个人在更新他们的本地副本时都会注意到新版本，然后运行pip install -E projectfoo-venv -r requirements.txt。
编辑：我删除了在pip中使用-U，这在pip8.2中是不需要的
pip/virtualenv编辑：与我目前的方法相比，pip/virtualenv的唯一优势似乎是当您在不同的项目上工作时，需要不同版本的。但是根据我的经验，当你需要不同版本的python时，你也需要不同版本的其他系统库(PIL，psycopg2，...)而virtualenv对此没有帮助(除非您疯狂到使用--no-site-package选项，即使这样它也是不完整的)。对于这种情况，我能想到的唯一解决方案是使用不同的虚拟机。
那么我错过了什么呢？有人能给我指出一个用例，在这个用例中，PIP或virtualenv会比我正在做的更好吗？
回答 3
Stack Overflow用户
发布于 2010-12-20 00:52:36
如果您有许多项目，并且不希望它们都共享相同的Python安装，那么virtualenv就会变得非常出色。例如，您可能有两个需求冲突项目。
Stack Overflow用户
发布于 2010-12-20 00:55:22
所有非仅python依赖项(PIL、psycopg2等)都记录在自述文件中，并安装在系统级别(apt-get install ...)
那么你不能对不同的项目有不同的依赖关系，也不能对不同的项目有这些依赖关系的不同版本。
这样做的一个影响是，您的本地安装不能准确地反映生产机器，因此您可能会在复制生产bug时遇到问题。
如果您安装的系统工具需要一个版本，您将被迫在任何地方使用相同的版本，这可能会破坏您的项目。
此外，还需要在系统python级别上取消删除模块。Virtualenv意味着您可以设置python安装来进行测试，而不会影响系统安装。
我绝对推荐为您的项目使用单独的python，并使用一些将Python与项目隔离的东西，如virtualenv或zc.buildout。
PIP只是一种更简单的安装模块的方法，它还可以帮助您卸载模块。
“我不可能使用virtualenv的-- no -site-packages选项在我的服务器上安装一个编译器和所有的构建依赖项，我不认为任何人真的在做这件事。”
不，我使用的是zc.buildout，但它相当于相同的东西，但工作量更少。;)
Stack Overflow用户
发布于 2010-12-20 00:59:50
对于我通常的项目，我按照你建议的方法，不使用pip/。这允许我把包放在特定的目录下。
+ext
|
|------python packages
+source
|
|------ project code and packages通常在启动脚本中，我会更新PYTHONPATH
export PYTHONPATH="";
export PYTHONPATH="${PYTHONPATH}:${workingdir}/path/to/ext";这具有保持项目和依赖项自包含的优点。我回应，你的想法在这里。
无论如何，我发现在中使用
，
- ，我必须用
something new做实验。当我想要使用them. - Another并比较
different related packages that can be used across projects.
的使用情况时，
- 甚至更好
例子：Documentation：一些关键的包，我已经安装了包括sphinx，pygraphwiz，nterworkX和一些更多的可视化包。我跨项目使用它，也将它放在系统级安装之外，以保持它不受污染。
我也希望你结账: Yolk.我发现它很好的结合了pip/。
您可以列出包
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)https://stackoverflow.com/questions/4483888
复制相似问题