pip 和 virtualenv 有什么好处？

Question

所以每个人都告诉我使用 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 文件，则该文件夹将保留，这可以很容易地 在更新本地副本之前删除所有 pyc 可以避免这种情况。

使用 PIP/virtualenv 升级仅包含 python 的依赖项：

您提交了需求文件的新版本，希望每个人都致力于该项目 项目在更新本地副本时会注意到新版本，然后 运行pip install -E projectfoo-venv -rrequirements.txt。

编辑：我删除了 pip 中 -U 的使用，pip 8.2 不需要这样做

编辑：pip/virtualenv 相对于我当前方法的唯一优势似乎是当你从事不同的项目，需要不同版本的Python。但 根据我的经验，当你需要不同版本的 python 时，你也可以 需要不同版本的其他系统库（PIL，psycopg2，...） 而 virtualenv 对此没有帮助（除非你足够疯狂 使用 --no-site-package 选项，即使这样它也是不完整的）。这 对于这种情况，我能想到的唯一解决方案是使用不同的虚拟机。

那我错过了什么？有人可以向我指出 PIP 或 virtualenv 的用例吗 会比我正在做的更好吗？

Answer 1

当您有多个项目并且不希望它们都共享相同的 Python 安装时，virtualenv 确实会发挥作用。例如，您可能有两个需求相互冲突的项目。

Answer 2

“所有非仅限 python 的依赖项（PIL、psycopg2 等）都记录在自述文件中并在系统级别安装（apt-get install ....）”

然后您就可以'不同的项目有不同的依赖项，并且不同项目的这些依赖项没有不同的版本。

其影响之一是您的本地安装无法准确反映生产计算机，因此您可能会在重现生产错误时遇到问题。

如果您安装需要一个版本的系统工具，您将被迫在所有地方使用相同的版本，这可能会破坏您的项目。

此外，取消删除模块需要在系统 python 级别完成。 Virtualenv 意味着您可以设置 python 安装来测试，而不会污染系统安装。

我绝对建议为您的项目使用单独的 python，并使用甚至将 Python 与项目隔离的东西，例如 virtualenv 或 zc.buildout。

PIP 只是一种更简单的安装模块的方法，它还可以帮助您卸载它们。

“我不可能使用 virtualenv 的 --no-site-packages 选项并在我的服务器上安装编译器和所有构建依赖项，我认为实际上没有人在这样做。 “

不，我使用 zc.buildout，但它的作用大致相同，但工作量更少。 ;)

Answer 3

对于我的日常项目，我按照您建议的方法进行操作，无需使用 pip/virtualenv。
这允许我将包放在特定目录中。

+ext
  |
  |------python packages
+source
  |
  |------ project code and packages

通常在启动脚本中我会更新 PYTHONPATH

export PYTHONPATH="";
export PYTHONPATH="${PYTHONPATH}:${workingdir}/path/to/ext";

这具有保持项目和依赖项独立的优点。我在这里回应你的想法。

时，我发现了 virtualenv 的用途

1. 然而，当我必须尝试新东西
2. 。当我想使用两个不同版本的包并比较它们时就更好了。
3. 另一个用途是，我保存可以跨项目使用的不同相关包。

例如：文档：我安装的一些关键软件包包括 sphinx、pygraphwiz、nterworkX 和更多可视化软件包。我在多个项目中使用它，并将其排除在系统级安装之外，以保持其不受污染。

我还想让你看看：Yolk。我发现 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)

Answer 4

使用 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

我所做的：我也“冻结”包，但我使用 pip 和 virtualenv 来执行此操作，并签入整个项目；包括 Python 包。所以我的部署与您的部署完全一样：

svn checkout https://myserver.com/svn/projectfoo/tags/1.0.0STABLE/site

使用 PIP/virtualenv 处理项目：

根据您的说法：

在项目foo上工作
cd 路径/到/项目
./manage.py 运行服务器 0:8000

我做什么：添加一个postactivate hook，如下所示：

$ cat bin/postactivate
cd $VIRTUAL_ENV
./manage.py runserver 0:8000
$

现在，更改为项目：

workon projectfoo