pip和virtualenv有什么好处?

djo*_*ume 23 python django pip

所以每个人都在告诉我使用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
Run Code Online (Sandbox Code Playgroud)

整个站点文件夹在我的存储库中检查(是的,包括所有仅限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/
Run Code Online (Sandbox Code Playgroud)

现在,在实践中,这与PIP/virtualenv相比如何?

使用我当前的方法部署项目:

svn checkout https://myserver.com/svn/projectfoo/tags/1.0.0STABLE/site
Run Code Online (Sandbox Code Playgroud)

使用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
Run Code Online (Sandbox Code Playgroud)

使用我当前的方法处理项目:

cd ~/projects/foo/site/projectfoo
export PYTHONPATH=.:..:../lib
./manage.py runserver 0:8000
Run Code Online (Sandbox Code Playgroud)

使用PIP/virtualenv处理项目:

workon projectfoo
cd path/to/project
./manage.py runserver 0:8000
Run Code Online (Sandbox Code Playgroud)

处理非python-only依赖项:

非python-only依赖项将以相同的方式处理,我无法使用--no-site-packagesvirtualenv 的选项并在我的服务器上安装编译器和所有构建依赖项,我认为没有人真正这样做无论如何.

使用我当前的方法升级仅限python的依赖项:

我在src中检出/解压缩新版本,从src中删除旧版本,更新lib中的符号链接并提交.现在,参与该项目的所有其他人都将在下一次svn up或更新时获得更新git pull.有一点不太好的是src中的旧文件夹将保留,如果它包含一些pyc文件,这可以通过在更新本地副本之前删除所有pyc轻松避免.

使用PIP/virtualenv升级仅限python的依赖项:

您提交了一个新版本的需求文件,希望每个在项目上工作的人在更新本地副本时都会注意到新版本然后运行pip install -E projectfoo-venv -r requirements.txt.

编辑:我用pip删除-U的使用,pip 8.2不需要这个

编辑:pip/virtualenv对我当前方法的唯一优势似乎是当你处理需要不同版本的python的不同项目时.但根据我的经验,当你需要不同版本的python时,你还需要不同版本的其他系统库(PIL,psycopg2,...),而virtualenv对此没有帮助(除非你疯狂到使用 - no-site-package选项,即使这样也不完整).我能想到的唯一解决方案是使用不同的虚拟机.

那我错过了什么?有人能指出一个PIP或virtualenv比我正在做的更好的用例吗?

Ned*_*der 14

当你有许多项目时,virtualenv真的很棒,并且不希望它们共享相同的Python安装.例如,您可能有两个具有冲突要求的项目.


Len*_*bro 7

"所有非python-only依赖项(PIL,psycopg2,...)都记录在README中并安装在系统级别(apt-get install ....)"

那么你不能为不同的项目提供不同的依赖关系,也不能为不同的项目提供不同版本的这些依赖关系.

其中一个影响是您的本地安装不能准确反映生产机器,因此您可能在重现生产错误时遇到问题.

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

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

我肯定建议为你的项目使用一个单独的python,并使用一些东西甚至将Python与项目隔离开来,比如virtualenv或zc.buildout.

PIP只是一种安装模块的简单方法,也可以帮助您卸载它们.

"我无法使用virtualenv的--no-site-packages选项,并在我的服务器上安装编译器和所有构建依赖项,我认为无论如何都不会有人这样做."

不,我使用zc.buildout,但它完全相同,但工作量减少.;)

  • @djoume:我不是在讨论不同版本的Python,而是讨论不同版本的依赖项.我会澄清一下.显然,如果每个项目有一个虚拟机,则不需要virtualenv. (3认同)