WSGI support in Django
Gustavo Narea
Over the last week I've been working to improve WSGI support in Django
and I have sent a few patches which have not received the feedback I
expected to have, so I wanted to ping you. ;-)
To be precise, with those patches Django applications would be able to:
1.- [Ticket 8927] Use WSGI middleware whose API should be dealt with in
the downstream Django application. For example, Django developers could
be able to use Repoze [1] middleware, like repoze.who or repoze.what,
which are widely used in TurboGears and Pylons.
2.- [Ticket 12075] Use third-party Django-independent libraries which
do stuff based on the URL arguments (not the query string, but those
named and positional arguments in the URL paths; the ones you define in
your `urlpatterns` variable).
3.- [Ticket 12091] This is the most exciting one. You'd be able to run
WSGI applications in a Django-lesque way. This is, you could "mount"
other applications in your Django views, dynamically, modifying the
request passed on to the WSGI app (as a Django request object) and
modify the application response (as a Django response object), if
needed.
For example, you could serve mercurial/SVN/etc repositories dynamically,
serve Trac install dynamically, etc. With the following Django view you
could mount Trac applications in the URL path /projects/{project-name}/:
=====
# "dosomething" module
import os
import site
from trac.web.main import dispatch_request as TracApp
from django.http import HttpResponse
from django.views.wsgi import call_wsgi_app
os.environ['PYTHON_EGG_CACHE'] = "/foo/bar/sampledjango/_eggs"
site.addsitedir('/bar/foo/Pyenvs/django-dev/lib/python2.5/site-packages')
def projects(request, project_name):
if not project_name:
return HttpResponse("Please specify a project in the URL!")
project_path = "/foo/bar/sampledjango/trackers/%s" % project_name
if not os.path.exists(project_path):
return HttpResponse("Project %s does not exist!" % project_name)
request.environ['trac.env_path'] = project_path
return call_wsgi_app(TracApp, request)
# The URL pattern for the view above would be:
# (r'^projects/(?P<project_name>[a-z]+)?', dosomething.projects),
=====
And if you already authenticated the user in your parent Django
application, the "children" WSGI applications will be aware that the
user was authenticated.
Please let me know what you think about it!
Cheers. :)
[1] http://repoze.org/repoze_components.html#middleware
--
Gustavo Narea.
Software Developer.
2degrees, Ltd.
Russell Keith-Magee
<gustav...@2degreesnetwork.com> wrote:
>
> Hi there.
>
> Over the last week I've been working to improve WSGI support in Django
> and I have sent a few patches which have not received the feedback I
> expected to have, so I wanted to ping you. ;-)
In the interests of good community relations, I want to clarify the
feedback you should be expecting.
Just because you've uploaded a patch doesn't mean you're going to get
immediate feedback. We're all volunteers, so our time is limited -
sometimes, this means that patches don't get triaged for a while.
Patience is required.
On top of that, we've just finished our feature discussion phase, and
we have nominated the features that are a high priority for the
project [1]. These are the features that will be receiving development
priority over the next few months. Features that aren't on this list
aren't going to get the immediate attention of the core team.
The feature list isn't completely locked off, though. Any feature with
a complete patch is potentially on the list for inclusion. However,
any feature that isn't on the list will require:
1) A champion in the core team to commit the code
2) A design and implementation that has been approved by the community
(as evidenced by discussion on django-dev)
That means you're going to need a member of the core team who is
excited about this possible feature. I can't speak for the other
members of the core team, but personally, this isn't a big itch. I can
certainly see how it could be useful, but I've already committed to
some big-ticket items that are much higher priorities for me
personally.
So - you need to have some patience. If you can't get a core developer
engaged as a result of this thread, you may need to wait until the
v1.3 feature discussion phase, which will open as soon as v1.2 is
finalized. Alternatively, you could help out with the features that we
have already agreed upon for v1.2, and maybe try to leverage the karma
you gain from doing that work into support for your WSGI patch.
[1] http://code.djangoproject.com/wiki/Version1.2Features
Yours,
Russ Magee %-)
Gustavo Narea
OK, I see what you mean, it sounds sensible.
Then I'd really appreciate if a core developer could take a look into
this. I think the advantages are very important, we're talking about
making Django more interoperable with other applications, and it'd
require little effort on your side:
- The patch for ticket 12075 is totally trivial. There can't be any
backwards incompatibilities.
- The patch for ticket 8927 is not trivial, but it's not complex
either. It's basically all about making the WSGI environment dictionary
available in mod_python, so the HttpRequest object can have a common API
across handlers.
- The patch for ticket 12091 is a bit complex, but it's a whole new
feature, we're not modifying an existing behavior (i.e., there can't be
backwards incompatibilities)... And, it has a unit test suite which
covers 100% of the new module.
I'd agree ticket 8927 is not that relevant to be included at this point
in the 1.2 branch, but for both #12075 and #12091, the WSGI environment
must be available.
If it helps, I could also write documentation for the above and send you
another patch.
Please let me know what you think,
- Gustavo.
Gustavo Narea
The features implemented in the patches are very important for us, so
I'd be more than happy to help with the development of v1.2 so you can
have more time to review these three patches.
We don't want to affect the development of Django 1.2, but at the same
time we'd really prefer to have this included in Django officially,
instead of having our patched version of Django.
If any of you is interested in trading tickets, please let me know. ;-)
Hoping-it-can-be-feasible'ly,
- Gustavo.
Gustavo Narea
One more update about the WSGI related improvements for Django:
I have created a Mercurial branch to keep track of these changes and
keep them synchronized with trunk:
http://bitbucket.org/Gustavo/django-wsgi/
Even though I know it's late for 1.2 at this point, please keep in mind
that part of these enhancements were supposed to be a high priority for
the 1.2 release [1] (GSoC-2). This branch implements more features than
the official http-wsgi-improvements branch and is complete/working. And
again, I am willing to help you with anything you need to get it merged,
such as writing docs and discussing the implementation further.
I hope to see these improvements in v1.3 then, even if it's not my
implementation.
Cheers,
- Gustavo.
[1] http://code.djangoproject.com/wiki/Version1.2Features#Highpriority
On Wed, 2009-10-28 at 08:24 +0800, Russell Keith-Magee wrote:
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com
> To unsubscribe from this group, send email to django-develop...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
--
Gustavo Narea.
Software Developer.
2degrees - the collaboration service for sustainable business.
http://www.2degreesnetwork.com/
Russell Keith-Magee
<gustav...@2degreesnetwork.com> wrote:
> Hi,
>
> One more update about the WSGI related improvements for Django:
>
> I have created a Mercurial branch to keep track of these changes and
> keep them synchronized with trunk:
> http://bitbucket.org/Gustavo/django-wsgi/
>
> Even though I know it's late for 1.2 at this point, please keep in mind
> that part of these enhancements were supposed to be a high priority for
> the 1.2 release [1] (GSoC-2). This branch implements more features than
> the official http-wsgi-improvements branch and is complete/working. And
> again, I am willing to help you with anything you need to get it merged,
> such as writing docs and discussing the implementation further.
There's a very important reason why the feature list is called 'High
Priority" and not "Must Have". We're all volunteers, so it's
impossible for us to know exactly how much time we will have to
dedicate to Django. Therefore, our goals need to be (and are)
expressed in terms of relative priorities, rather than in terms of
absolutes.
Malcolm was the champion behind GSOC-2; unfortunately, Malcolm has
been buried under real-life and work stuff, so he hasn't been able to
shepherd the GSOC-2 changes into trunk. This is unfortunate, but there
isn't much we can do about this.
Yours,
Russ Magee %-)
Evert Carton
From: Russell Keith-Magee <freakb...@gmail.com>
To: django-d...@googlegroups.com
Sent: Tue, 5 January, 2010 0:44:57
Subject: Re: WSGI support in Django
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group, send email to django-developers+unsub...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.