Django:哪种方法更好 [ virtualenv + pip] vs [在svn中手动携带包]?
我有一个 django 项目,使用了很多第三方应用程序,因此想决定使用两种方法来管理我的情况:
- 我可以使用 [ virtualenv + pip ] 以及
pip freeze
作为需求文件来管理我的项目依赖项。<块引用> <块引用>我不必担心应用程序,但不能将其与我的代码一起提交到 svn。
- 我可以在 svn 结构中有一个 lib 文件夹,并将我的应用程序放在那里并将其添加到 sys.path 中
sys.path
我应该走哪条路?
每种方法的优点和缺点是什么?
更新:
<块引用>方法 1 缺点:难以与 appengine 配合使用。
I have a django project that uses a lot of 3rd party apps, so wanted to decide out of the two approaches to manage my situation :
- I can use [ virtualenv + pip ] along with
pip freeze
as requirements file to manage my project dependencies.I don't have to worry about the apps, but can't have that committed with my code to svn.
- I can have a lib folder in my svn structure and have my apps sit there and add that to
sys.path
This way, my dependencies can be committed to svn, but I have to manage sys.path
Which way should I proceed ?
What are the pros and cons of each approach ?
Update:
Method1 Disadvantage : Difficult to work with appengine.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
到目前为止,这个问题还没有答案(至少对我来说)。最近对此有一些讨论:-
https://plus.google.com/u/0/104537541227697934010/posts/a4kJ9e1UUqE
Ian Bicking 在评论中这样说道:-
http://tarekziade.wordpress.com/ 2012/02/10/defining-a-wsgi-app-deployment-standard/
第一种方法似乎是 python 开发人员中最常见的方法。当我第一次开始在 Django 中进行开发时,感觉有点奇怪,因为在使用 PHP 时,将第三方库检查到项目存储库中是很常见的,但正如 Ian Bicking 在链接文章中所说,PHP 风格部署遗漏了诸如此类的非-便携式图书馆。您不想将诸如 mysqldb 或 PIL 之类的东西打包到您的项目中,最好由 Pip 或 Distribution 等工具来处理。
This has been unanswered question (at least to me) so far. There're some discussion on this recently:-
https://plus.google.com/u/0/104537541227697934010/posts/a4kJ9e1UUqE
Ian Bicking said this in the comment:-
http://tarekziade.wordpress.com/2012/02/10/defining-a-wsgi-app-deployment-standard/
The first approach seem the most common among python devs. When I first started doing development in Django, it feels a bit weird since when doing PHP, it quite common to check third party lib into the project repo but as Ian Bicking said in the linked post, PHP style deployment leaves out thing such non-portable library. You don't want to package things such as mysqldb or PIL into your project which better being handled by tools like Pip or distribute.
这就是我目前正在使用的。
所有项目都会在项目根目录下有 virtualenv 目录。我们将其命名为.env,并在vcs中忽略它。开发人员在开始开发时所做的第一件事是初始化此 virtualenv 并安装在requirements.txt 文件中指定的所有需求。我更喜欢将 virtualenv 放在项目目录中,这样对开发人员来说很明显,而不是将其放在其他地方,例如
$HOME/.virtualenv
,然后执行source $HOME/virtualenv/project_name/bin /activate
激活环境。相反,开发人员通过直接从项目根调用 env 可执行文件来与 virtualenv 交互,例如:-为了部署,我们有一个 Fabric 脚本,它首先将项目目录与 .env 目录一起导出到 tarball 中,然后将 tarball 复制到实时服务器,解压部署目录并执行一些其他任务,例如重新启动服务器等。当我们在实时服务器上解压 tarball 时,fabric 脚本确保再次运行 virtualenv,以便所有 shebang 路径都在
.env/bin
已修复。这意味着我们不必在实时服务器上再次重新安装依赖项。用于部署的结构工作流程如下所示: -我们也不使用 setup.py 将项目 src 安装到 virtualenv 中,而是将其路径添加到 sys.path 中。因此,在 mod_wsgi 下部署时,我们必须在 vhost 配置中为 mod_wsgi 指定 2 个路径,如下所示:-
简而言之:
So this is what I'm using currently.
All projects will have virtualenv directory at the project root. We name it as .env and ignore it in vcs. The first thing dev did when to start doing development is to initialize this virtualenv and install all requirements specified in requirements.txt file. I prefer having virtualenv inside project dir so that it obvious to developer rather than having it in some other place such as
$HOME/.virtualenv
and then doingsource $HOME/virtualenv/project_name/bin/activate
to activate the environment. Instead developer interact with the virtualenv by invoking the env executable directly from project root, such as:-To deploy, we have a fabric script that will first export our project directory together with the .env directory into a tarball, then copy the tarball to live server, untar it deployment dir and do some other tasks like restarting the server etc. When we untar the tarball on live server, the fabric script make sure to run virtualenv once again so that all the shebang path in
.env/bin
get fixed. This mean we don't have to reinstall dependencies again on live server. The fabric workflow for deployment will look like:-We also do not install project src into virtualenv using setup.py but instead add path to it to sys.path. So when deploying under mod_wsgi, we have to specify 2 paths in our vhost config for mod_wsgi, something like:-
In short:
Virtualenv 和 pip 非常适合在一台机器上处理多个 django 项目。但是,如果您只有一个正在编辑的项目,则没有必要使用 virtualenv。
Virtualenv and pip are fantastic for working on multiple django projects on one machine. However, if you only have one project that you are editing, it is not necessary to use virtualenv.