Django:哪种方法更好 [ virtualenv + pip] vs [在svn中手动携带包]?

发布于 2025-01-04 22:20:35 字数 590 浏览 4 评论 0原文

我有一个 django 项目,使用了很多第三方应用程序,因此想决定使用两种方法来管理我的情况:

  1. 我可以使用 [ virtualenv + pip ] 以及 pip freeze 作为需求文件来管理我的项目依赖项。

    <块引用> <块引用>

    我不必担心应用程序,但不能将其与我的代码一起提交到 svn。

  2. 我可以在 svn 结构中有一个 lib 文件夹,并将我的应用程序放在那里并将其添加到 sys.path 中
This way, my dependencies can be committed to svn, but I have to manage 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 :

  1. 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.

  2. 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

风追烟花雨 2025-01-11 22:20:35

到目前为止,这个问题还没有答案(至少对我来说)。最近对此有一些讨论:-

https://plus.google.com/u/0/104537541227697934010/posts/a4kJ9e1UUqE

Ian Bicking 在评论中这样说道:-

我确实认为我们可以做一些整合这两个系统的事情。我
例如,早些时候发布了一个处理此问题的方法(我想我
应该清理它并重新发布)。您可以非常轻松地处理库
Python 中的方式类似,同时仍然使用我们必须管理的工具
那些图书馆。你可以做到这一点,但如何做到这一点并不明显
这样做,所以人们倾向于依赖重新安装软件包之类的事情
在部署时。

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:-

I do think we can do something that incorporates both systems. I
posted a recipe for handling this earlier, for instance (I suppose I
should clean it up and repost it). You can handle libraries in a very
similar way in Python, while still using the tools we have to manage
those libraries. You can do that, but it's not at all obvious how to
do that, so people tend to rely on things like reinstalling packages
at deploy time.

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.

此生挚爱伱 2025-01-11 22:20:35

这就是我目前正在使用的。

所有项目都会在项目根目录下有 virtualenv 目录。我们将其命名为.env,并在vcs中忽略它。开发人员在开始开发时所做的第一件事是初始化此 virtualenv 并安装在requirements.txt 文件中指定的所有需求。我更喜欢将 virtualenv 放在项目目录中,这样对开发人员来说很明显,而不是将其放在其他地方,例如 $HOME/.virtualenv ,然后执行 source $HOME/virtualenv/project_name/bin /activate 激活环境。相反,开发人员通过直接从项目根调用 env 可执行文件来与 virtualenv 交互,例如:-

.env/bin/python
.env/bin/python manage.py runserver

为了部署,我们有一个 Fabric 脚本,它首先将项目目录与 .env 目录一起导出到 tarball 中,然后将 tarball 复制到实时服务器,解压部署目录并执行一些其他任务,例如重新启动服务器等。当我们在实时服务器上解压 tarball 时,fabric 脚本确保再次运行 virtualenv,以便所有 shebang 路径都在.env/bin 已修复。这意味着我们不必在实时服务器上再次重新安装依赖项。用于部署的结构工作流程如下所示: -

fab create_release:1.1 # create release-1.1.tar.gz
fab deploy:1.1 # copy release-1.1.tar.gz to live server and do the deployment tasks
fab deploy:1.1,reset_env=1 # same as above but recreate virtualenv and re-install all dependencies
fab deploy:1.1,update_pkg=1 # only reinstall deps but do not destroy previous virtualenv like above

我们也不使用 setup.py 将项目 src 安装到 virtualenv 中,而是将其路径添加到 sys.path 中。因此,在 mod_wsgi 下部署时,我们必须在 vhost 配置中为 mod_wsgi 指定 2 个路径,如下所示:-

WSGIDaemonProcess project1 user=joe group=joe processes=1 threads=25 python-path=/path/to/project1/.env/lib/python2.6/site-packages:/path/to/project1/src

简而言之:

  1. 我们仍然使用 pip+virtualenv 来管理依赖项。
  2. 部署时我们不必重新安装需求。
  3. 我们必须稍微维护 sys.path 的路径。

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 doing source $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:-

.env/bin/python
.env/bin/python manage.py runserver

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:-

fab create_release:1.1 # create release-1.1.tar.gz
fab deploy:1.1 # copy release-1.1.tar.gz to live server and do the deployment tasks
fab deploy:1.1,reset_env=1 # same as above but recreate virtualenv and re-install all dependencies
fab deploy:1.1,update_pkg=1 # only reinstall deps but do not destroy previous virtualenv like above

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:-

WSGIDaemonProcess project1 user=joe group=joe processes=1 threads=25 python-path=/path/to/project1/.env/lib/python2.6/site-packages:/path/to/project1/src

In short:

  1. We still use pip+virtualenv to manage dependencies.
  2. We don't have to reinstall requirements when deploying.
  3. We have to maintain path into sys.path a bit.
灼疼热情 2025-01-11 22:20:35

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文