Re: Support for WSGI applications within Django (Ticket #12091)

[Gustavo Narea]

Hello, everybody.

Sorry for re-opening this old conversation, but I still haven't heard from 
you.

I'm not sure whether that means that there's no interest in this, or it's 
just that you've been busy.

Cheers,

 - Gustavo.

On Friday, September 6, 2013 11:51:01 AM UTC+1, Gustavo Narea wrote:
>
> Hello, Jacob et al.
>
> I was wondering whether there's an update on this.
>
> I'm still interested to learn about the concerns about the implementation, 
> so that I can know what to focus on. And also whether it's even worth me 
> doing a new implementation.
>
> Cheers,
>
>  - Gustavo.
>
>
> On Thursday, April 18, 2013 9:22:34 AM UTC+1, Gustavo Narea wrote:
>>
>> Hello,
>>
>> Any update on this?
>>
>> Cheers.
>>
>>  - Gustavo.
>>
>> On Friday, April 12, 2013 3:29:49 PM UTC+1, Gustavo Narea wrote:
>>>
>>> Hi Jacob,
>>>
>>> On Friday, April 12, 2013 3:09:40 PM UTC+1, Jacob Kaplan-Moss wrote:
>>>>
>>>> On Fri, Apr 12, 2013 at 8:54 AM, Gustavo Narea 
>>>> <gustav...@2degreesnetwork.com> wrote: 
>>>> > So I guess that means that it won't be considered for inclusion in 
>>>> Django? 
>>>> > If so, I'll close that ticket. 
>>>>
>>>> Hm, I wouldn't be so hasty -- it's something I, at least, would like to 
>>>> include. 
>>>>
>>>> Of course, the concerns about the implementation are still there, and 
>>>> they're non-trivial. So my actual yes/no would be based more on the 
>>>> concrete proposal. But I think it'd be a good idea to include in core 
>>>> *if* it can be done well. 
>>>>
>>>> I know it's a lot to ask given the mixed messages so far, but would 
>>>> you be OK preparing a patch/pull request for us to discuss? 
>>>>
>>>
>>> I'm glad to hear you're interested.
>>>
>>> I'm absolutely confident that it can be done well. (I'm pretty familiar 
>>> with WSGI and Django's handlers implementation, and I've been using my 
>>> implementation in a high-traffic site for 3 years with not a single bug 
>>> found so far.)
>>>
>>> I'd be happy to update the patch I attached to the ticket and make a 
>>> pull request. But before I go ahead and spend time doing that, would you 
>>> mind if I address any concerns that you may still have now? I'd prefer to 
>>> save the time if it's not going to be accepted anyway.
>>>
>>> Cheers,
>>>
>>>  - Gustavo.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/bd992d07-a4b1-48a0-8c6d-d2d5ea9d01bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Support for WSGI applications within Django (Ticket #12091)

[Gustavo Narea]

Hello, Jacob et al.

I was wondering whether there's an update on this.

I'm still interested to learn about the concerns about the implementation, 
so that I can know what to focus on. And also whether it's even worth me 
doing a new implementation.

Cheers,

 - Gustavo.


On Thursday, April 18, 2013 9:22:34 AM UTC+1, Gustavo Narea wrote:
>
> Hello,
>
> Any update on this?
>
> Cheers.
>
>  - Gustavo.
>
> On Friday, April 12, 2013 3:29:49 PM UTC+1, Gustavo Narea wrote:
>>
>> Hi Jacob,
>>
>> On Friday, April 12, 2013 3:09:40 PM UTC+1, Jacob Kaplan-Moss wrote:
>>>
>>> On Fri, Apr 12, 2013 at 8:54 AM, Gustavo Narea 
>>> <gustav...@2degreesnetwork.com> wrote: 
>>> > So I guess that means that it won't be considered for inclusion in 
>>> Django? 
>>> > If so, I'll close that ticket. 
>>>
>>> Hm, I wouldn't be so hasty -- it's something I, at least, would like to 
>>> include. 
>>>
>>> Of course, the concerns about the implementation are still there, and 
>>> they're non-trivial. So my actual yes/no would be based more on the 
>>> concrete proposal. But I think it'd be a good idea to include in core 
>>> *if* it can be done well. 
>>>
>>> I know it's a lot to ask given the mixed messages so far, but would 
>>> you be OK preparing a patch/pull request for us to discuss? 
>>>
>>
>> I'm glad to hear you're interested.
>>
>> I'm absolutely confident that it can be done well. (I'm pretty familiar 
>> with WSGI and Django's handlers implementation, and I've been using my 
>> implementation in a high-traffic site for 3 years with not a single bug 
>> found so far.)
>>
>> I'd be happy to update the patch I attached to the ticket and make a pull 
>> request. But before I go ahead and spend time doing that, would you mind if 
>> I address any concerns that you may still have now? I'd prefer to save the 
>> time if it's not going to be accepted anyway.
>>
>> Cheers,
>>
>>  - Gustavo.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Support for WSGI applications within Django (Ticket #12091)

[Gustavo Narea]

Hello,

Any update on this?

Cheers.

 - Gustavo.

On Friday, April 12, 2013 3:29:49 PM UTC+1, Gustavo Narea wrote:
>
> Hi Jacob,
>
> On Friday, April 12, 2013 3:09:40 PM UTC+1, Jacob Kaplan-Moss wrote:
>>
>> On Fri, Apr 12, 2013 at 8:54 AM, Gustavo Narea 
>> <gustav...@2degreesnetwork.com> wrote: 
>> > So I guess that means that it won't be considered for inclusion in 
>> Django? 
>> > If so, I'll close that ticket. 
>>
>> Hm, I wouldn't be so hasty -- it's something I, at least, would like to 
>> include. 
>>
>> Of course, the concerns about the implementation are still there, and 
>> they're non-trivial. So my actual yes/no would be based more on the 
>> concrete proposal. But I think it'd be a good idea to include in core 
>> *if* it can be done well. 
>>
>> I know it's a lot to ask given the mixed messages so far, but would 
>> you be OK preparing a patch/pull request for us to discuss? 
>>
>
> I'm glad to hear you're interested.
>
> I'm absolutely confident that it can be done well. (I'm pretty familiar 
> with WSGI and Django's handlers implementation, and I've been using my 
> implementation in a high-traffic site for 3 years with not a single bug 
> found so far.)
>
> I'd be happy to update the patch I attached to the ticket and make a pull 
> request. But before I go ahead and spend time doing that, would you mind if 
> I address any concerns that you may still have now? I'd prefer to save the 
> time if it's not going to be accepted anyway.
>
> Cheers,
>
>  - Gustavo.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Support for WSGI applications within Django (Ticket #12091)

[Gustavo Narea]

Hi Jacob,

On Friday, April 12, 2013 3:09:40 PM UTC+1, Jacob Kaplan-Moss wrote:
>
> On Fri, Apr 12, 2013 at 8:54 AM, Gustavo Narea 
> <gustav...@2degreesnetwork.com > wrote: 
> > So I guess that means that it won't be considered for inclusion in 
> Django? 
> > If so, I'll close that ticket. 
>
> Hm, I wouldn't be so hasty -- it's something I, at least, would like to 
> include. 
>
> Of course, the concerns about the implementation are still there, and 
> they're non-trivial. So my actual yes/no would be based more on the 
> concrete proposal. But I think it'd be a good idea to include in core 
> *if* it can be done well. 
>
> I know it's a lot to ask given the mixed messages so far, but would 
> you be OK preparing a patch/pull request for us to discuss? 
>

I'm glad to hear you're interested.

I'm absolutely confident that it can be done well. (I'm pretty familiar 
with WSGI and Django's handlers implementation, and I've been using my 
implementation in a high-traffic site for 3 years with not a single bug 
found so far.)

I'd be happy to update the patch I attached to the ticket and make a pull 
request. But before I go ahead and spend time doing that, would you mind if 
I address any concerns that you may still have now? I'd prefer to save the 
time if it's not going to be accepted anyway.

Cheers,

 - Gustavo.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Support for WSGI applications within Django (Ticket #12091)

[Gustavo Narea]

Hello, Carl and Alex,

You're right: Apart from not being able to embed Django sites, there's 
nothing preventing twod.wsgi from working with Django as it is now.

So I guess that means that it won't be considered for inclusion in Django? 
If so, I'll close that ticket.

Cheers,

 - Gustavo.



On Thursday, April 11, 2013 3:31:51 PM UTC+1, Gustavo Narea wrote:
>
> Hello, everybody.
>
> In the interest of finding a resolution to Ticket 
> #12091<https://code.djangoproject.com/ticket/12091>, a 
> 3-year-old ticket, I wanted to bring this issue to your attention.
>
> I think that Django should have built-in support for running WSGI 
> applications from inside views. (NB: I really mean running WSGI apps from 
> inside Django views -- I'm not talking about using a WSGI middleware that 
> routes requests to your Django project or another WSGI application.)
>
> If you're able to embed WSGI applications in your Django project, you'd be 
> able to do many things. For example:
>
>- Control access to static files, while still letting your Web server 
>do the file transfer: http://pythonhosted.org/xsendfile/
>- Re-use your Django-based authentication in other applications, even 
>applications not written in Python. For example, if your Django site runs 
>at "/" and your Wordpress blog and Trac instance live at "/blog/" and 
>"/tickets/", respectively, your users would only have to log in once if 
>your Django site proxies requests to Wordpress and Trac. Here's how I've 
>integrate them in the past: https://bitbucket.org/Gustavo/weesgo/ and 
>http://gustavonarea.net/files/talks/europython2010/all-materials.zip
>- Alter the response returned by another web application or web site, 
>using HttpResponse objects.
>
> It basically comes down to being able to integrate other applications and 
> websites, and then filter the requests they get and/or the responses they 
> return -- Using Django request and response objects.
>
> I decided to reimplement the patch I created 3 years ago in a separate 
> project 
> (twod.wsgi<http://pythonhosted.org/twod.wsgi/manual/embedded-apps.html>), 
> which means that it's possible to do this without changing Django. However, 
> it doesn't support embedding Django projects because of Django's use of 
> global data (DJANGO_SETTINGS_MODULE and django.conf.settings), which I 
> think can only be solved by introducing thread locals in django.conf. At 
> the moment, the only way to accomplish this would be by proxying the second 
> Django site with inter-process communication (e.g., CGI, FastCGI or HTTP).
>
> I'm not going to insist on adding support for embedding other Django 
> projects, because I personally haven't had the need to do that and 
> introducing thread locals in django.conf may be controversial. But I guess 
> it might be useful to other people.
>
> So, do you agree that Django should have built-in support for running WSGI 
> applications from inside views?
>
> Thanks in advance!
>
>  - Gustavo Narea.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Support for WSGI applications within Django (Ticket #12091)

[Gustavo Narea]

Hello, everybody.

In the interest of finding a resolution to Ticket 
#12091<https://code.djangoproject.com/ticket/12091>, a 
3-year-old ticket, I wanted to bring this issue to your attention.

I think that Django should have built-in support for running WSGI 
applications from inside views. (NB: I really mean running WSGI apps from 
inside Django views -- I'm not talking about using a WSGI middleware that 
routes requests to your Django project or another WSGI application.)

If you're able to embed WSGI applications in your Django project, you'd be 
able to do many things. For example:

   - Control access to static files, while still letting your Web server do 
   the file transfer: http://pythonhosted.org/xsendfile/
   - Re-use your Django-based authentication in other applications, even 
   applications not written in Python. For example, if your Django site runs 
   at "/" and your Wordpress blog and Trac instance live at "/blog/" and 
   "/tickets/", respectively, your users would only have to log in once if 
   your Django site proxies requests to Wordpress and Trac. Here's how I've 
   integrate them in the past: https://bitbucket.org/Gustavo/weesgo/ 
   and http://gustavonarea.net/files/talks/europython2010/all-materials.zip
   - Alter the response returned by another web application or web site, 
   using HttpResponse objects.

It basically comes down to being able to integrate other applications and 
websites, and then filter the requests they get and/or the responses they 
return -- Using Django request and response objects.

I decided to reimplement the patch I created 3 years ago in a separate 
project 
(twod.wsgi<http://pythonhosted.org/twod.wsgi/manual/embedded-apps.html>), 
which means that it's possible to do this without changing Django. However, 
it doesn't support embedding Django projects because of Django's use of 
global data (DJANGO_SETTINGS_MODULE and django.conf.settings), which I 
think can only be solved by introducing thread locals in django.conf. At 
the moment, the only way to accomplish this would be by proxying the second 
Django site with inter-process communication (e.g., CGI, FastCGI or HTTP).

I'm not going to insist on adding support for embedding other Django 
projects, because I personally haven't had the need to do that and 
introducing thread locals in django.conf may be controversial. But I guess 
it might be useful to other people.

So, do you agree that Django should have built-in support for running WSGI 
applications from inside views?

Thanks in advance!

 - Gustavo Narea.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: State of X-Sendfile support?

[Gustavo Narea]

On 26/03/11 11:31, Graham Dumpleton wrote:
>
> Yes and no as nginx also has a X-Sendfile module, again possibly
> optional (can't remember).

I didn't know there was an X-Sendfile module for Nginx -- Search results
for "nginx xsendfile" point me to X-Accel-Redirect.


> In Apache/mod_wsgi when using daemon mode you have CGI style
> 200/Location to use as well.
>
> So, you have a mix of file system path and URL based schemes. In the
> case of file system based schemes, because the code processing
> X-Sendfile is potentially a different process, then you also have to
> deal with issues of that other process not having the required
> permissions to access the file even though the original application did.
>
> For URL based schemes, nginx has an easy way to designate the URLs
> which are the target of X-Accel-Redirect are private and only
> accessible from a sub request triggered by the header. For Apache when
> using 200/Location, you have to use a mod_rewrite rule to effect
> private URLs.
>
> Other proxy/load balancing front ends such a Pound and Squid (???)
> also support their own headers for this sort of URL sub requests.
>
> Add to this wsgi.file_wrapper and you have three different schemes one
> can use. For the case of URL mechanism, there also various headers and
> consumers of the headers.

I think wsgi.file_wrapper is a different beast. I would not try to
support it along with X-Sendfile/X-Accel-Redirect/Location.


> In short, it is all a mess and trying to provide support for it in one
> bit of code is possibly asking a bit much.

I agree with you. However, I think trying to offer some kind of common
abstraction may still be beneficial.

Cheers.

-- 
Gustavo Narea.
Software Developer.
2degrees, Ltd. <http://www.2degreesnetwork.com/>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: State of X-Sendfile support?

[Gustavo Narea]

On 26/03/11 00:17, Graham Dumpleton wrote:
>
> Why guess in the first place? Apache and Nginx both support
> 'X-Sendfile:
> ' don't they? (older nginx seemed to only support their
> own syntax, though).
>
> Apache requires a separate module to be installed which isn't part of
> the core, so no you can't rely on it being present.

Indeed. Plus, the meaning of the path you give to the server has a
totally different meaning in Nginx, compared to that Apache module.

In that Apache module and Lighttpd, the path set in the "X-Sendfile"
header is a path on the filesystem. In Nginx (header "X-Accel-Redirect")
and CGI (heder "Location"), the path is a URL path within the same host.

-- 
Gustavo Narea.
Software Developer.
2degrees, Ltd. <http://www.2degreesnetwork.com/>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: State of X-Sendfile support?

[Gustavo Narea]

On 25/03/11 14:50, Thomas Guettler wrote:
> Maybe you are right. Guessing is bad. But I think to write "nginx" into
> the application code is bad, too. Something like this could be in settings.py.

I think you're diverging: My point is simply to illustrate how to use
wsgi-xsendfile. You wouldn't hard code the path to the file either, and
yet that's how I've done it in my example.

-- 
Gustavo Narea.
Software Developer.
2degrees, Ltd. <http://www.2degreesnetwork.com/>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: State of X-Sendfile support?

[Gustavo Narea]

Hi all,

Just to let you know that there's an X-Sendfile implementation for
WSGI apps (inc. Django), which also works with Nginx:
https://launchpad.net/wsgi-xsendfile

You can use it in Django views via twod.wsgi. For example:

"""
from twod.wsgi import call_wsgi_app
from xsendfile import NginxSendfile

file_sender = NginxSendfile('/var/www/docs')
file_sender_wsgi_app = XSendfileApplication('/media/documents',
file_sender)

def django_view(request, article_id):
article = Article.objects.get(article_id)
if it's foggy:
doc_response = call_wsgi_app(
file_sender_wsgi_app,
request,
article.path,
)
else:
doc_response = HttpResponseForbidden()

return doc_response
"""

That package is pretty stable, the only thing it's missing is
documentation which should be sorted soon.

Cheers.

 - Gustavo.

On Mar 25, 6:50 am, Waldemar Kornewald  wrote:
> On Thursday, March 24, 2011 2:40:39 PM UTC+1, Kristaps Kūlis wrote:
>
> > I wish to note that Nginx implements this feature differently than
> > LigHTTPd and Apache2
> >http://wiki.nginx.org/XSendfile,
>
> > Should django implementation consider that ?
>
> > My proposal to implement would be:
> >  1. HttpFileResponse which takes file location (relative to MEDIA_URL ?)
> >  2. HttpFileResponse checks for settings.X_SENDFILE or
> > settings.X_ACCEL_REDIRECT and modifies sets revelant headers
> > (Content-Type, X-Sendfile, X-Accel-Redirect) etc. HttpFileResponse
> > should fallback to outputting file if no accelerated redirect is
> > available.
> >  3. Update docs, showing example server config .
> >  4. Tests
>
> > I could provide patch, if design idea is ok .
>
> You might also be interested in this ticket which goes a little bit further
> in abstracting file uploads and downloads not only for X-Sendfile, but also
> S3, App Engine, and other file hosting/serving 
> solutions:http://code.djangoproject.com/ticket/13960
>
> The patch is not great. It's too complicated, both implementation-wise (esp.
> in django.forms) and usability-wise (esp. the transfer_id stuff which is
> used for assigning backends to uploads/downloads).
>
> For the sake of completeness, here is a separate app with the same 
> purpose:http://www.allbuttonspressed.com/projects/django-filetransfers
> The API can certainly be simplified some more and I plan to do that probably
> in May.
>
> I hope some of this is useful to you.
>
> Bye,
> Waldemar
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Making WSGIHandler the only handler / mod_python support

[Gustavo Narea]

Hello,

On 23 June, 01:00, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> On Wed, Jun 23, 2010 at 7:22 AM, Gustavo Narea <m...@gustavonarea.net> wrote:
> > To sum up, I'm proposing two things:
> >  1.- Making the WSGI handler the only handler.
> >  2.- If we want to keep mod_python support, use a mod_python<->WSGI wrapper.
>
> > What do you think?
>
> As noted in a separate thread -- we're looking to deprecate
> mod_python. The mod_python code will need to linger and remain
> operational for a couple of releases, but I have no problem if you
> ignore mod_python for the purposes of your changes.

OK, that sounds good.

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: 1.3: Start deprecating mod_python?

[Gustavo Narea]

Whoops, I wan't aware of this topic when I posted this:

http://groups.google.com/group/django-developers/browse_thread/thread/2e20f4ae486800a1

Anyway, I'm +1 on this.

On Jun 22, 10:47 pm, Robert Coup  wrote:
> Hey folks,
>
> While people are throwing around 1.3 ideas... I think we should start
> the process of deprecating and removing support for mod_python. Why?
>
>  * mod_wsgi is better in every way.
>  * mod_python hasn't had a release since 2007, or a commit since 2008;
> it's a dead end. The Apache Foundation board voted this month to
> retire it to the "Attic" - effectively beginning to wind it 
> up.http://attic.apache.org/projects/quetzalcoatl.html
>  * if people are still using it in production in 2012, it is easy to
> maintain an external handler.
>
> I'm proposing the following very predictable timeline:
>
> Django 1.3
>     Use of the modpython handler raises a PendingDeprecationWarning.
> Update the docs to discourage people from using it.
> Django 1.4
>     Use of the modpython handler raises a DeprecationWarning.
> Django 1.5
>     Remove the modpython handler from Django (and put it on bitbucket/github?)
>
> If someone magically steps up and brings it back to life, we can
> always halt/reverse the process.
>
> Objections?
>
> Rob :)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Making WSGIHandler the only handler / mod_python support

[Gustavo Narea]

Hello,

I'm going to work on some patches to improve WSGI support, and I found 
something that, if changed, could make my patches and django.core.handlers 
simpler... As well as make it possible to use WSGI middleware with Django 
under mod_python.

At the moment, Django has two so-called handlers: One for any WSGI gateway 
like mod_wsgi, and another just for mod_python. Each handler has its own 
request class. And the handlers and the request classes have their respective 
base classes:
+ BaseHandler
  - WSGIHandler
  - ModPythonHandler
+ HttpRequest
  - WSGIRequest
  - ModPythonRequest

Instead of having these 6 classes, we could get rid of the mod_python handler, 
and then merge the base and WSGI handlers together to have just "Handler" (or 
"HttpHandler") and "HttpRequest", with no subclasses.

I don't know if the Django community wants to keep support for mod_python now 
that it's officially dead. If so, I would suggest using a mod_python<->WSGI 
wrapper, which I believe is better than having a separate handler:

 1.- There would be only one type of request, which means:
 - It'd be less likely for a Django application to behave differently on 
mod_python vs mod_wsgi; or mod_python vs FastCGI; etc.
 - All the new WSGI-related features I am implementing will be 
automatically available under mod_python.
 2.- It'd be possible to use WSGI middleware under mod_python.

There would be three ways to keep support for mod_python with the two 
advantages above:
 1.- Adapting the existing code the mod_python handler and also applying the 
changes I proposed in the patch for ticket #8927.
 2.- Copying the following module (Public Domain) into Django:
http://www.aminus.net/browser/modpython_gateway.py
 3.- Not adding mod_python support in Django itself, but instead recommend 
using a mod_python<->WSGI wrapper like paste.modwsgi:
http://bitbucket.org/ianb/paste/src/tip/paste/modpython.py

I am willing to provide a patch for this and I wouldn't mind using any of 
these three approaches. But if you ask me, I think no one should be using 
mod_python at this point and therefore I'd suggest dropping support for 
mod_python (the 3rd option):
http://blog.dscpl.com.au/2010/05/modpython-project-soon-to-be-officially.html
http://blog.dscpl.com.au/2010/06/modpython-project-is-now-officially.html

To sum up, I'm proposing two things:
 1.- Making the WSGI handler the only handler.
 2.- If we want to keep mod_python support, use a mod_python<->WSGI wrapper.

What do you think?

PS: You may want to see the latest comments on Ticket #8927:
http://code.djangoproject.com/ticket/8927
-- 
Gustavo Narea .
| Tech blog: =Gustavo/(+blog)/tech  ~  About me: =Gustavo/about |

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Gustavo Narea]

Hello.

On Jun 14, 1:39 pm, Russell Keith-Magee 
wrote:
> Ok - at this point, I'm broadly happy with your proposals (subject to
> the caveats I've given along the way). The next step is to show us
> actual code. This won't get applied to trunk as a single monolithic
> "fix WSGI" patch - it needs to be (at least) 4 patches, one for each
> feature that is being added, and each patch will need to be tested
> (and if appropriate, documented). Each of these features should also
> be logged as a ticket (if they aren't already).
>
> If you're looking to maximize the likelihood that this will land in
> trunk, the best approach will be to concentrate on one of the four
> issues (preferably starting with a small one), and see it through to
> completion; then move onto the next issue, and so on.


I've started to work on this, but I'm kind of stuck because I don't
know where to put the tests.

The first patch (wsgiorg.routing_args implementation; #12075) would
involve adding a couple of lines to
django.core.handlers.base:BaseHandler.get_response() (to put the
arguments in the request) and also adding a couple of methods in
HttpRequest to access pythonically the so-called positional and named
arguments in the request, so we'd need tests for these two components
(i.e., the request and the handler).

I found an existing test suite for request objects (regressiontests/
requests/tests.py), but it has only ~6 doctests and I'm not sure if
you really want me to introduce these new tests as doctests, given
that the rest of the test suite seems to use regular unit tests.

As for tests for the handlers, I wasn't able to find any; /
regressiontests/servers/tests.py is the closest thing I found, but I'm
not sure that handler-related tests fit there. If I had to add a new
test suite, I thought it would be best to create it for WSGI-related
tests in tests/regressiontests/wsgi/ because it could be reused by my
future patches.

What do you think I should do?

Thanks in advance.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Gustavo Narea]

On 16/06/10 10:48, Graham Dumpleton wrote:
> But that will not happen if you use a different hosting mechanism.
> Thus you end up with a fiddle as documented in:
>
>   http://wiki.pylonshq.com/display/pylonscookbook/Logging+under+mod_wsgi
>
> The point I am making is that these hosting system specific fiddles
> should never need to be done by a user.
>   

Right, I see your point.

-- 
Gustavo Narea.
Software Developer.
2degrees, Ltd. <http://www.2degreesnetwork.com/>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Gustavo Narea]

Hello.

On 16/06/10 01:33, Graham Dumpleton wrote:
> Paste has its own problems. Paste server itself does process
> environment setup that isn't done by other WSGI hosting mechanisms.
> Specifically, it initialises Python logging in a way suited to Paste
> based applications. Like with Django development server, you can
> develop a Paste based application on Paste server which will then not
> work on other WSGI hosting mechanisms.
>   

Paste Script will set up logging its way if and only if you explicitly
tell it to; i.e., defining logging configuration in the Paste Deploy
file or passing an argument to `paster'. I cannot think of another thing
that it does at startup time which may affect deployment, but I may be
wrong.

I think there's always the risk of things working on a development
server but not on the production environment, but the thing is how that
risk can be minimized.


> There certainly is a larger problem I also want to address beyond
> pointing out the issues with Django deployment, but I haven't even
> mentioned them in these posts and don't intend to.
>
> What you are trying to do with using Paste Script/Deploy is tinkering
> at the edges of a larger issue you probably don't even know exists or
> don't appreciate. Paste Script/Deploy will not solve that larger issue
> as there are lots of things it doesn't do. Adopting it will only make
> it harder to solve the real problems later on.
>
> Trying to address the bigger issue is going to need some cooperation
> between all frameworks and hosting solution authors to come up with a
> consistent way of doing certain stuff. Right now though I don't have
> time to lay out properly what the issues are or implement a proof of
> concept which illustrates the direction one could take to solve the
> problem. It may be the case that Paste Script/Deploy could be adapted
> to meet that requirement at some point, but by itself, because the
> focus of Paste Deploy is more about constructing WSGI components
> together to create an application, as opposed to solving the problem
> of deployment on a specific hosting mechanism, I feel right now it is
> a poor choice.
>
> If time allows I hope to talk to Russell about some of this stuff when
> he is at PyCon in Sydney, but it will still need a lot more work after
> that.
>
> Ultimately if something doesn't get done to address the bigger issues,
> the WSGI deployment (distinct from composing together WSGI components
> into an application), will continue to be a dogs breakfast.
>   

I have no idea what those problems are, so I never meant to solve them.
I just found two issues and Paste Deploy/Script seemed like a solution.

I'm curious about them though. I'll keep an eye on your blog and Web-SIG.

-- 
Gustavo Narea.
Software Developer.
2degrees, Ltd. <http://www.2degreesnetwork.com/>.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Gustavo Narea]

Hello, Graham.

Graham said:
> From what I remember of this thread, haven't been following it too
> closely though, I would think the idea of relying on WebOb and Paste
> Deploy is a bad idea.
> 
> There are bigger issues around WSGI deployment that need to be solved
> and using Paste Deploy as it is now would only make those larger
> deployment issues even harder to solve in a clean way.

Initially, I suggested Paste Script as a replacement for the development 
server because it doesn't do any Django-specific thing at startup time, which 
then may lead to inconsistencies on deployment.

I did suggest Paste Deploy, but not to solve said inconsistencies. It was 
because of the INI configuration which also supports adding WSGI middleware 
declaratively.

But both of them were ruled out in this thread.

Could you please elaborate on why relying on WebOb would be a bad idea?

Cheers.
-- 
Gustavo Narea .
| Tech blog: =Gustavo/(+blog)/tech  ~  About me: =Gustavo/about |

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Gustavo Narea]

etime object.

Here's the complete list of getters/setters:
http://pythonpaste.org/webob/class-webob.Request.html
and, just in case, here's the source code:
http://bitbucket.org/ianb/webob/src/tip/webob/request.py#cl-88

If these reasons are not enough to add WebOb as a dependency, I'm still 
willing to provide a patch to at least make WSGIRequest propagate the relevant 
changes to the WSGI environ, which is my #1 concern.


> Ok - at this point, I'm broadly happy with your proposals (subject to
> the caveats I've given along the way). The next step is to show us
> actual code. This won't get applied to trunk as a single monolithic
> "fix WSGI" patch - it needs to be (at least) 4 patches, one for each
> feature that is being added, and each patch will need to be tested
> (and if appropriate, documented). Each of these features should also
> be logged as a ticket (if they aren't already).
> 
> If you're looking to maximize the likelihood that this will land in
> trunk, the best approach will be to concentrate on one of the four
> issues (preferably starting with a small one), and see it through to
> completion; then move onto the next issue, and so on.

That sounds good to me. I'll get to work on the patch to make WSGI middleware 
possible in the development server.


> >> I'm also interested how this relates to the work that was done on
> >> Django's WSGI interface during last year's GSoC. Are you at all
> >> familiar with the work on this branch? If so, what is the extent of
> >> the overlap between your code and that branch?
> > 
> > AFAIR, that branch would've solved (3) only.
> 
> It might only solve (3) from your list, but I'm pretty sure it solves
> a bunch of other issues as well. The final diff for the branch
> contains a lot of code, and theoretically represents 12 weeks of
> full-time work; I may have to try poking Chris Cahoon off-list for a
> description of what is contained in his branch. If there is other ore
> in that branch (and I suspect there is), we should be aiming to mine
> it.

Yes, it's likely it also does more things. I checked that branch ~7 months 
ago.

Cheers.
-- 
Gustavo Narea .
| Tech blog: =Gustavo/(+blog)/tech  ~  About me: =Gustavo/about |

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Gustavo Narea]

Hello,

Not that I want to rush this, but have you had time to read my last
email or made a decision? :-)

Cheers,

 - Gustavo.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Gustavo Narea]

Hello, Russell et al.

I am not saying that Django's WSGI implementation doesn't comply with
the specification. In fact, I've been talking about improving "WSGI
support" not "WSGI compliance".

It does comply with the specification, but just internally without
exposing all the WSGI-related functionality that could be consumed by
3rd party libraries. In other words, Django plays well with the
gateway using WSGI, but makes it really hard for a third component to
come into play.

I should've been more precise and have said "Open up WSGI support for
3rd party libraries", instead of simply "improve WSGI support".


On Jun 2, 4:54 pm, Russell Keith-Magee 
wrote:
> > That's right, although the proposal is not mainly to add Paste as a
> > dependency, but support WSGI middleware in a transparent way; for
> > example, the way Paste Deploy does.
>
> The issue I'm unclear on is what you mean by "transparent". Django
> provides an interface that implements the WSGI spec. There may well be
> errors in that implementation or violations of the spec, and if there
> are, I'm happy to address them. But ultimately, we either implement
> the spec or we don't.
>
> If Django's implementation of the WSGI spec is compliant, but you
> can't use it with out WSGI components, then to my reading either the
> other components aren't implementing the spec, or the WSGI spec is
> missing something big.

By "transparent" I mean that you can wrap Django with WSGI middleware
and the resulting callable would be the final WSGI application that
should be taken by the development and deployment gateway (for
example, `manage runserver' and mod_wsgi, respectively).

This callable could be the same in both scenarios, unless the
developer explicitly changes it.


> > The reason why I proposed Paste is because it's widely used and it'd
> > prevent us from implementing something that is already implemented.
>
> Your argument also presupposes that Paste is an inherently better
> implementation. Well, I don't wan't to brag, but Django also has an
> implemented WSGI implementation, and it's just as battle hardened as
> Paste. :-)
>
> I won't argue that duplication of code and effort is a virtue. If
> there is a benefit to be gained in leveraging someone else's work, and
> we can do so without compromising our own project, then we should.
> However, this raises the much larger issue of how to manage Django's
> relationship with external libraries in a way that maintains our
> 'beginner friendly' history. The 'minimal dependency' philosophy is,
> in my opinion, one of the reasons that Django has been able to get the
> traction that it has gained.

If the changes I'm proposing are accepted, not only we'd keep
backwards compatibility, but also all the documentation written so far
will still be relevant.

We wouldn't be changing existing behavior, but adding new
functionality for "advanced" users. Things would only change for those
of us who write framework-independent WSGI libraries and Django users
who want to integrate such libraries.


> There have been some initial discussions about this general problem --
> specifically, in relation to introducing support for unittest2.
> However, it's a discussion that is much larger than improving WSGI
> support, and it's a discussion that we need to have as a community.

I agree with that.


> > There are lots of WSGI middleware out there that you may want/need to
> > use, and there are even projects like Paste or Repoze whose only goal
> > is to develop framework-independent WSGI libraries (many if not most
> > of them are middleware). In the following links you can find some of
> > the WSGI middleware available and find that most of them are
> > applicable to both development and deployment:
> >http://pythonpaste.org/modindex.html(some items aren't middleware,
> > but WSGI applications)
> >http://repoze.org/repoze_components.html#middleware
> >http://wsgi.org/wsgi/Middleware_and_Utilities
>
> > Some of them are alternatives to components offered by Django itself,
> > which some people might prefer to use. Others are just things that
> > cannot/shouldn't be done at the framework level.
>
> > I'll give you one real-world example:
>
> > We don't put all the static files under MEDIA_ROOT for the limitations
> > described on  > browse_thread/thread/b333c14f40acd22a>. We have four kind of static
> > files and we want them to be in different directories:
>
> >  - Front-end files, like JS or CSS.
> >  - Files generated by our application, like thumbnails.
> >  - Uploaded files.
> >  - Uploaded files whose downloads are restricted.
>
> This is a great example of a use case where you shouldn't be using
> Django's development server at all. You have a bunch of serving rules
> for static content. A proper web server can handle those. But as far
> as developing and testing your Django application is concerned, it
> shouldn't matter how the static files 

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Gustavo Narea]

On Jun 2, 9:26 am, Reinout van Rees <rein...@vanrees.org> wrote:
> On 05/29/2010 01:51 AM, Gustavo Narea wrote:
> > Basically, when you need to integrate a piece of WSGI middleware that
> > must be present both on development and deployment, you have to get
> > rid of `manage runserver' and use a development server like the one
> > from Paste or CherryPy.
>
> Middleware that *must* be present: it reminded me of an old blog post
> that warned about mandatory middleware. I think I've read it in more
> than one place, though:
>
> http://dirtsimple.org/2007/02/wsgi-middleware-considered-harmful.html
>
> The core idea of that post is that if something is mandatory, it isn't
> middleware anymore.  It should be part of your application.  I don't
> really have an opinion about this myself (yet).

I completely disagree with that, but regardless of what we think,
there are lots of middleware out there that expose an API that is used
inside the WSGI application, and doing so is so common that frameworks
like Pylons set up new projects like that. And Django developers may
need/want to use that kind of middleware.

> Do you know what the current way of thinking on this is?

I'm guessing that a very tiny portion of the people who use WSGI don't
like it, presumably because of the reasons described in that post from
2007.

 - Gustavo.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Gustavo Narea]

s particularly
> > useful for 3rd party WSGI libraries and the dispatching components in
> > Web frameworks are expected to set it, but Django does not: Therefore
> > we created the RoutingArgsMiddleware  Django middleware.
>
> > If you requested the path /blog/posts/hello-world/comments/3, then the
> > arguments hello-world and 3 will be available in the request object.
> > Depending on how you defined your URL patterns, they’ll be a
> > dictionary (if you used named groups) or a tuple (if you didn’t set
> > names for the matching groups). The former are referred to as “named
> > arguments” and the later as “positional arguments” in routing_args
> > specification.
>
> > RoutingArgsMiddleware simply puts the arguments found by the Django
> > URL resolver in the request object. It’s such a simple thing, but it’s
> > key for Django-independent libraries, which may not be run in the
> > context of a Django middleware nor a Django view."
>
> Ok; so here you're proposing that Django support an extension to the
> WSGI specification for which Django provides an alternate
> implementation. Until routing args becomes part of the WSGI spec, this
> strikes me as something that *should* be housed in an external
> project.

That is an official extension from the Python Web-SIG, the same that
maintains the WSGI specification, and Django doesn't even provide
something similar AFAIK.

Put simply, the routing_args specification requires dispatchers to put
the arguments found in the URL in the WSGI environment dictionary.
Django doesn't put this information in the WSGI environ (or in the
request object, AFAIR), but it's something absolutely trivial to
solve.

This is an implementation in the form of Django middleware, but I
believe an appropriate solution would be to do it in the WSGI handler:
http://bitbucket.org/2degrees/twod.wsgi/src/tip/twod/wsgi/middleware.py



> > Serving static files (aka "media")
> > --
>
> > Letting a WSGI application serve static files on development servers
> > is better because it's faster (given that Django won't get run) and
> > more importantly, Django doesn't serve the media on deployment after
> > all.
>
> Again - why should we care about this? We don't need to massively
> optimize the devserver; it's a nasty hack to get a test site working
> for development purposes. If you have a real deployment, you shouldn't
> be using the Django stack to serve media -- you should be using a
> lightweight web server that has high throughput for handles files.
> This is something that is clearly documented in Django's own docs.

Fair enough.


> We're aware that we haven't been the most responsive citizens when it
> comes to working with the rest of the Python web community, and we
> certainly intend to get more active with the WSGI specification
> process -- especially as it relates to the Python 3 transition.
> However, that doesn't mean we're about to completely change the way
> Django works in order to support aspects of the WSGI spec that the
> Django community has been able to live without, or for which the
> Django community has alternate approaches. We're entirely happy to
> accept changes that make Django more WSGI compliant; we're not going
> to be so responsive to changes that try to make Django into a
> different web framework.

The changes I am proposing are all backwards compatible. None of them
require a major rewrite of the framework. And more importantly, people
who don't need these advanced features won't notice any difference*.
So, I don't see any of the things I have proposed as a risk of turning
Django into a different framework.

To sum up, this proposal is all about improving WSGI support in
Django. Adding Paste as a dependency is the approach I personally
recommend for technical reasons, and also because I'd see it as one
step toward a better relationship with the rest of the Python Web
community, which would be beneficial for all of us.

And to be honest, I don't think making history of not having
dependencies is necesarily a good thing. If a 3rd party library would
improve considerably a part of Django, I think it should be added
instead of duplicating efforts to come up with a not-so-good solution
tied to Django. And in this case, I think Paste is a better solution;
the result of the effort put by the wider WSGI community, which Django
could use without breaking backwards compatibility.

Cheers,

 - Gustavo Narea.

* Even if you decide to replace the built-in development server with
Paste's, you could run it from "manage runserver"... And so people
will continue to run the same command.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Gustavo Narea]

OMG, I didn't realize that the very long email I wrote last night was
trimmed by Google Groups.

Let me take a deep breath and write it again... :'(


On May 29, 12:51 am, Gustavo Narea <m...@gustavonarea.net> wrote:
> Hello,
>
> On May 28, 6:13 pm, Russell Keith-Magee <russ...@keith-magee.com>
> wrote:
>
> > This is all very helpful information; thanks for breaking it down like this.
>
> > I've talked this over with a few people at the sprints, and we've
> > pretty much ended up at the same point -- we're deeply confused.
> > Comments inline below.
>
> Thank you very much for taking time to talk about it. :)
>
> Sorry, I think I didn't explain some components well and that led to
> the confusion. I'll try to do it better this time...
>
> > I also want to be very clear -- this feedback is *not* us saying "go
> > away", it's us saying "we're not clear on what you're proposing and
> > why you're proposing it". Please take this criticism in the sprit it
> > is intended -- to work out exactly what it is that we *aren't* doing,
> > and more importantly, *why* we should be doing it another way.
>
> Sure, I understand.
>
>
>
>
>
> > > Paste Deploy application factory instead of `manage runserver'
> > > --
>
> > > The problem with running the application in development mode is that
> > > there's no way to add WSGI middleware, it's like Django assumes that
> > > you'd only need WSGI middleware on deployment.
>
> > > Therefore I think we should either adopt Paste Script's development
> > > server (which makes your app behave like it'd do under mod_wsgi, for
> > > example; with no Django-specific magic) or implement a development
> > > server that serves the WSGI application you give it (which could be
> > > wrapped around WSGI middleware, or it could not even be a Django
> > > application).
>
> > > I'd prefer sticking to Paste Script's server because it's multi-
> > > threaded and we could *optionally* use Paste Deploy configuration
> > > files, instead of Python files for configuration:
> > >http://packages.python.org/twod.wsgi/manual/paste-factory.html
>
> > So - what you seem to be proposing here is that we add Paste as a
> > dependency of Django in order to support:
>
> >  1) A format of configuration that is different to Django's
> >  2) Support for WSGI middlewares in the development server
>
> That's right, although the proposal is not mainly to add Paste as a
> dependency, but support WSGI middleware in a transparent way; for
> example, the way Paste Deploy does.
>
> The reason why I proposed Paste is because it's widely used and it'd
> prevent us from implementing something that is already implemented.
>
> > Despite your protestations, (1) is a matter of opinion, and it's not
> > an opinion I happen to share. Personally, I really like the fact that
> > Django's configuration files are Python files and not Yet Another
> > Configuration Format; I also contest the assertion that INI files are
> > more configurable.
>
> I agree it's a matter of opinion, and I also have to say that's
> secondary. I'm not that interested in changing the configuration
> system, at least not within this WSGI-related proposal: I just wanted
> to point out another advantage of using Paste, which you could use if
> you want to (it wouldn't be mandatory).
>
> > (2) isn't a matter of opinion; however, it's not a use case that I've
> > seen a particularly compelling use case for, either. I'm certainly
> > willing to be convinced otherwise, though -- now is your opportunity
> > to convince us.
>
> Basically, when you need to integrate a piece of WSGI middleware that
> must be present both on development and deployment, you have to get
> rid of `manage runserver' and use a development server like the one
> from Paste or CherryPy.
>
> There are lots of WSGI middleware out there that you may want/need to
> use, and there are even projects like Paste or Repoze whose only goal
> is to develop framework-independent WSGI libraries (many if not most
> of them are middleware). In the following links you can find some of
> the WSGI middleware available and find that most of them are
> applicable to both development and 
> deployment:http://pythonpaste.org/modindex.html(some items aren't middleware,
> but WSGI applications)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Gustavo Narea]

Hello,

On May 28, 6:13 pm, Russell Keith-Magee 
wrote:
> This is all very helpful information; thanks for breaking it down like this.
>
> I've talked this over with a few people at the sprints, and we've
> pretty much ended up at the same point -- we're deeply confused.
> Comments inline below.

Thank you very much for taking time to talk about it. :)

Sorry, I think I didn't explain some components well and that led to
the confusion. I'll try to do it better this time...


> I also want to be very clear -- this feedback is *not* us saying "go
> away", it's us saying "we're not clear on what you're proposing and
> why you're proposing it". Please take this criticism in the sprit it
> is intended -- to work out exactly what it is that we *aren't* doing,
> and more importantly, *why* we should be doing it another way.

Sure, I understand.


> > Paste Deploy application factory instead of `manage runserver'
> > --
>
> > The problem with running the application in development mode is that
> > there's no way to add WSGI middleware, it's like Django assumes that
> > you'd only need WSGI middleware on deployment.
>
> > Therefore I think we should either adopt Paste Script's development
> > server (which makes your app behave like it'd do under mod_wsgi, for
> > example; with no Django-specific magic) or implement a development
> > server that serves the WSGI application you give it (which could be
> > wrapped around WSGI middleware, or it could not even be a Django
> > application).
>
> > I'd prefer sticking to Paste Script's server because it's multi-
> > threaded and we could *optionally* use Paste Deploy configuration
> > files, instead of Python files for configuration:
> >http://packages.python.org/twod.wsgi/manual/paste-factory.html
>
> So - what you seem to be proposing here is that we add Paste as a
> dependency of Django in order to support:
>
>  1) A format of configuration that is different to Django's
>  2) Support for WSGI middlewares in the development server


That's right, although the proposal is not mainly to add Paste as a
dependency, but support WSGI middleware in a transparent way; for
example, the way Paste Deploy does.

The reason why I proposed Paste is because it's widely used and it'd
prevent us from implementing something that is already implemented.


> Despite your protestations, (1) is a matter of opinion, and it's not
> an opinion I happen to share. Personally, I really like the fact that
> Django's configuration files are Python files and not Yet Another
> Configuration Format; I also contest the assertion that INI files are
> more configurable.

I agree it's a matter of opinion, and I also have to say that's
secondary. I'm not that interested in changing the configuration
system, at least not within this WSGI-related proposal: I just wanted
to point out another advantage of using Paste, which you could use if
you want to (it wouldn't be mandatory).


> (2) isn't a matter of opinion; however, it's not a use case that I've
> seen a particularly compelling use case for, either. I'm certainly
> willing to be convinced otherwise, though -- now is your opportunity
> to convince us.

Basically, when you need to integrate a piece of WSGI middleware that
must be present both on development and deployment, you have to get
rid of `manage runserver' and use a development server like the one
from Paste or CherryPy.

There are lots of WSGI middleware out there that you may want/need to
use, and there are even projects like Paste or Repoze whose only goal
is to develop framework-independent WSGI libraries (many if not most
of them are middleware). In the following links you can find some of
the WSGI middleware available and find that most of them are
applicable to both development and deployment:
http://pythonpaste.org/modindex.html (some items aren't middleware,
but WSGI applications)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Gustavo Narea]

Sorry, I forgot to link to the embedded application docs:
http://packages.python.org/twod.wsgi/manual/embedded-apps.html

On May 27, 10:08 am, Gustavo Narea <gna...@tech.2degreesnetwork.com>
wrote:
> Hello,
>
> On May 26, 4:52 pm, Ivan Sagalaev <man...@softwaremaniacs.org> wrote:
>
> > Could you please give a concise technical overview, in high-level terms,
> > on what twod.wsgi actually does to Django code?
>
> Sure. There are different components, so I'll elaborate on them
> individually:
>
> Paste Deploy application factory instead of `manage runserver'
> --
>
> The problem with running the application in development mode is that
> there's no way to add WSGI middleware, it's like Django assumes that
> you'd only need WSGI middleware on deployment.
>
> Therefore I think we should either adopt Paste Script's development
> server (which makes your app behave like it'd do under mod_wsgi, for
> example; with no Django-specific magic) or implement a development
> server that serves the WSGI application you give it (which could be
> wrapped around WSGI middleware, or it could not even be a Django
> application).
>
> I'd prefer sticking to Paste Script's server because it's multi-
> threaded and we could *optionally* use Paste Deploy configuration
> files, instead of Python files for 
> configuration:http://packages.python.org/twod.wsgi/manual/paste-factory.html
>
> (And one of the advantages of using INI files for configuration
> instead of Python code is that it's a lot easier to 
> extend:http://packages.python.org/twod.wsgi/manual/paste-factory.html#multip...)
>
> Better request objects
> --
>
> There are two problems with Django's request objects from a WSGI point
> of view:
>
> - It copies the WSGI environment variables. That makes
> interoperability with WSGI libraries harder or not possible at all,
> because the request can be changed but the WSGI environ wouldn't be
> modified, and vice versa, if the WSGI environ is modified the request
> wouldn't be updated.
> - It doesn't expose an API to handle most of the properties of a
> request -- only the most common ones.
>
> WebOb's request object is a better proxy of the WSGI environ from my
> point of view, which is why I think Django's request object should
> extend it. It doesn't have the problems above and it has more
> features:http://packages.python.org/twod.wsgi/manual/request-objects.html
>
> I've managed to sub-class both WebOb.Request and Django's HttpRequest
> without breaking backwards compatibility.
>
> Embedded WSGI applications
> --
>
> At present there's no built-in mechanism to run WSGI applications from
> Django. Doing so could be extremely powerful and useful in some
> situations, because it gives you the ability to filter the request
> another application receives, and the response it returns -- Using
> request and response objects, respectively.
>
> And by "WSGI" application, I mean pretty much *any* Web application.
> Java applications, PHP applications, a Web site likewww.google.com.
> Anything, thanks to 3rd party WSGI applications that can run CGI
> scripts and proxies, for 
> example:http://pythonpaste.org/modules/cgiapp.html#paste.cgiapp.CGIApplicationhttp://pythonpaste.org/modules/proxy.html#paste.proxy.Proxy
>
> So, if you have, say, a Trac instance running on your Web site, you
> can make it use Django's authentication data for the current user, and
> authenticate users with your own Django-powered login form, and log
> users out from Django, and many other things. Check this sample Django
> application that implements a Single Sign-On mechanism with 
> Trac:http://bitbucket.org/Gustavo/weesgo/
>
> URL routing arguments support
> -
>
> From the manual <http://packages.python.org/twod.wsgi/manual/routing-
> args.html>:
>
> "routing_args  is an extension to the WSGI standard which normalises
> the place to put the arguments found in the URL. This is particularly
> useful for 3rd party WSGI libraries and the dispatching components in
> Web frameworks are expected to set it, but Django does not: Therefore
> we created the RoutingArgsMiddleware  Django middleware.
>
> If you requested the path /blog/posts/hello-world/comments/3, then the
> arguments hello-world and 3 will be available in the request object.
> Depending on how you defined your URL patterns, they’ll be a
> dictionary (if you used named groups) or a tuple (if you didn’t set
> names for the matching groups). The former are referred to as “named
> arguments” and the later as “positional arguments” in routing_

Re: Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Gustavo Narea]

Hello,

On May 26, 4:52 pm, Ivan Sagalaev  wrote:
> Could you please give a concise technical overview, in high-level terms,
> on what twod.wsgi actually does to Django code?

Sure. There are different components, so I'll elaborate on them
individually:


Paste Deploy application factory instead of `manage runserver'
--

The problem with running the application in development mode is that
there's no way to add WSGI middleware, it's like Django assumes that
you'd only need WSGI middleware on deployment.

Therefore I think we should either adopt Paste Script's development
server (which makes your app behave like it'd do under mod_wsgi, for
example; with no Django-specific magic) or implement a development
server that serves the WSGI application you give it (which could be
wrapped around WSGI middleware, or it could not even be a Django
application).

I'd prefer sticking to Paste Script's server because it's multi-
threaded and we could *optionally* use Paste Deploy configuration
files, instead of Python files for configuration:
http://packages.python.org/twod.wsgi/manual/paste-factory.html

(And one of the advantages of using INI files for configuration
instead of Python code is that it's a lot easier to extend:
http://packages.python.org/twod.wsgi/manual/paste-factory.html#multiple-configuration-files)


Better request objects
--

There are two problems with Django's request objects from a WSGI point
of view:

- It copies the WSGI environment variables. That makes
interoperability with WSGI libraries harder or not possible at all,
because the request can be changed but the WSGI environ wouldn't be
modified, and vice versa, if the WSGI environ is modified the request
wouldn't be updated.
- It doesn't expose an API to handle most of the properties of a
request -- only the most common ones.

WebOb's request object is a better proxy of the WSGI environ from my
point of view, which is why I think Django's request object should
extend it. It doesn't have the problems above and it has more
features:
http://packages.python.org/twod.wsgi/manual/request-objects.html

I've managed to sub-class both WebOb.Request and Django's HttpRequest
without breaking backwards compatibility.


Embedded WSGI applications
--

At present there's no built-in mechanism to run WSGI applications from
Django. Doing so could be extremely powerful and useful in some
situations, because it gives you the ability to filter the request
another application receives, and the response it returns -- Using
request and response objects, respectively.

And by "WSGI" application, I mean pretty much *any* Web application.
Java applications, PHP applications, a Web site like www.google.com.
Anything, thanks to 3rd party WSGI applications that can run CGI
scripts and proxies, for example:
http://pythonpaste.org/modules/cgiapp.html#paste.cgiapp.CGIApplication
http://pythonpaste.org/modules/proxy.html#paste.proxy.Proxy

So, if you have, say, a Trac instance running on your Web site, you
can make it use Django's authentication data for the current user, and
authenticate users with your own Django-powered login form, and log
users out from Django, and many other things. Check this sample Django
application that implements a Single Sign-On mechanism with Trac:
http://bitbucket.org/Gustavo/weesgo/


URL routing arguments support
-

>From the manual :

"routing_args  is an extension to the WSGI standard which normalises
the place to put the arguments found in the URL. This is particularly
useful for 3rd party WSGI libraries and the dispatching components in
Web frameworks are expected to set it, but Django does not: Therefore
we created the RoutingArgsMiddleware  Django middleware.

If you requested the path /blog/posts/hello-world/comments/3, then the
arguments hello-world and 3 will be available in the request object.
Depending on how you defined your URL patterns, they’ll be a
dictionary (if you used named groups) or a tuple (if you didn’t set
names for the matching groups). The former are referred to as “named
arguments” and the later as “positional arguments” in routing_args
specification.

RoutingArgsMiddleware simply puts the arguments found by the Django
URL resolver in the request object. It’s such a simple thing, but it’s
key for Django-independent libraries, which may not be run in the
context of a Django middleware nor a Django view."


Serving static files (aka "media")
--

Letting a WSGI application serve static files on development servers
is better because it's faster (given that Django won't get run) and
more importantly, Django doesn't serve the media on deployment after
all.

See: http://packages.python.org/twod.wsgi/manual/media-apps.html


That's it, AFAIR. Please let me know what you 

Re: DjangoCon.eu is on right now

[Gustavo Narea]

Hello, Russell et al.

On May 24, 10:37 am, Russell Keith-Magee 
wrote:
> We will be sprinting at the conference on Thursday and Friday. If you
> have a detailed proposal that would benefit from some round-table
> discussion while several core developers are in the same room, please
> post your proposal and we'll try to discuss it.

I have one: 
http://groups.google.com/group/django-developers/browse_thread/thread/5c92a9ea7caae978

If you need more details about how things work, you may check the
manual (it's fully documented) or the source code:
http://packages.python.org/twod.wsgi/manual/
http://bitbucket.org/2degrees/twod.wsgi/src

 - Gustavo  :)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Proposal: First-class WSGI support in Django 1.3 / twod.wsgi

[Gustavo Narea]

Hello, everyone.

I'd like Django's WSGI support to be as good as in the other WSGI frameworks 
(or better).

With this in mind, I have developed a project called twod.wsgi [1] which brings 
full WSGI capabilities to Django, whether running in development or deployment. 
This project is fully tested, 100% backwards compatible and has now been in use 
for over 5 months in a production environment. 

Ideally I think full WSGI support is something that should be available 
out-of-the-box in Django and therefore I want to contribute it to Django. (And 
I'm reopening this discussion, as suggested when I tried to push it to Django 
1.2 [2].)

Among many other things, one of the components alone provides solutions to some 
enterprise requirements for Django 
<http://groups.google.com/group/django-developers/browse_thread/thread/c89e028a536514d3>:

 * It’s now possible to run code at startup time, in a straight-forward yet 
extremely flexible fashion, which will also work on development servers if you 
want it to – not only when deployed on a production server. 
 * You can now stop using a Python module to store your application settings, 
in order to use an intuitive and widely used
mechanism that scales up and scales down. It will just work and you won’t have 
to update any other file in your application. 
 * By providing full WSGI support in development mode, we are able to  work 
around the differences in the process environment between django development 
server and django hosted using mod_wsgi 
<http://blog.dscpl.com.au/2010/03/improved-wsgi-script-for-use-with.html>
 * It’s finally possible to run WSGI middleware in development servers, the 
same way you may do it on production servers. 

And this is just the tip of the iceberg. By improving Django’s 
interoperability, we would gain the ability to rapidly integrate many pieces of 
third party software with Django, or simply use a component which outperforms 
Django’s current implementation for your requirements.

If you want to read more about how we’ve done this, you can look here: 
http://packages.python.org/twod.wsgi/manual/index.html#introduction

We're willing to work closely with the core development team to adapt twod.wsgi 
if necessary and integrate it in Django 1.3.

What do you think?

 - Gustavo Narea.

[1] http://packages.python.org/twod.wsgi/
[2] 
http://groups.google.com/group/django-developers/browse_thread/thread/08c7ffeee7b9343c

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Process discussion: reboot

[Gustavo Narea]

Hello,

I'm glad someone from the core development team brings this up.

I've lost motivation to contribute to Django after the many failed
attempts to improve WSGI support. I consider myself of the users Shawn
Milochik describes: "There is frustration on the part of some Django
users who would like to contribute but feel that anyone not in the
core dev team is a third-class citizen with a tiny voice, and think
that spending any time working on a ticket is slightly less likely to
be worthwhile than writing an iPhone app and hoping Apple approves it
for the App Store ".

I am involved in many other Free Software projects and I can tell you
Django is the least contributor-friendly out of them. I can understand
that implementing feature requests is not something exciting if you
contribute in your spare time and you're not particularly interested
in that feature, but leaving potential contributors behind is
something I wouldn't understand.

My two cents,

 - Gustavo.


On Apr 19, 3:19 pm, Jacob Kaplan-Moss  wrote:
> Hi folks --
>
> I'd like to try to reboot the discussion that's been going on about
> Django's development process.
>
> I'm finding the current thread incredibly demoralizing: there's a
> bunch of frustration being expressed, and I hear that, but I'm having
> trouble finding any concrete suggestions. Instead, the thread has
> devolved into just going around in circles on the same small handful
> of issues.
>
> So: here's your chance. You have suggestions about Django's
> development process? Make them. I'm listening.
>
> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/django-developers?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: dbsettings, and user configurable app settings

[Gustavo Narea]

I'd suggest using PasteDeploy:
http://packages.python.org/twod.wsgi/manual/paste-factory.html

I can't see a reason to reinvent the wheel with a Django-specific
thing, while this widely used method is rock-solid. It's the one used
in frameworks like Pylons and TurboGears,

On Feb 26, 7:11 am, Jared Forsyth  wrote:
> I have been looking around for a way of managing user-configurable
> application settings, and the only solution I have found is dbsettings,
> which looks like it hasn't been touched in 3 years.
> So, I would like to know: is dbsettings dead? Or is there a different
> generally accepted method for having user-friendly app settings? (e.g. don't
> require code modification)
>
> I think that this idea is pretty essential to django's ease of use; there
> are many applications which have (or should have) settings which only effect
> UI or minor behavioral issues, and shouldn't require a server restart to
> effect (and imo shouldn't require server write access). It seems that the
> most viable solution would be to have a database managed settings system (in
> the form of a .contrib module) which would manage this. It also seems that
> having such an infrastructure in place would really encourage app
> maintainers to have more settings, thereby making the apps even more
> portable.
>
> Any thoughts?
>
> Thanks,
> Jared

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Status of branch soc2009/http-wsgi-improvements? (and ticket 2131)

[Gustavo Narea]

Hello, Jari.

I'd recommend using twod.wsgi instead: http://bitbucket.org/2degrees/twod.wsgi/

It's very stable, full-feature and truly WSGI compliant. We've been
using heavily over the last 2 months. It started from this:
http://groups.google.com/group/django-developers/browse_thread/thread/08c7ffeee7b9343c

We'll release it officially soon, once I finish the documentation.
With twod,wsgi, you'd do the following:

from twod.wsgi import call_wsgi_app
from paste.fileapp import FileApp

def django_view(file_to_serve):
return call_wsgi_app(FileApp(file_to_serve))


But note you'd need to use twod.wsgi's handler, which in a simple sub-
class of Django's WSGI handler. And because Django doesn't allow you
to use a different handler nor WSGI middleware in the development
server, you wouldn't be able to use that server. That's no big deal,
because you can use any server, including PasteScript (the one used by
all the other WSGI frameworks; which I personally believe outperforms
Django's).

So, you could use the following Paste file:

# whatever.ini
[DEFAULT]
debug = True

[server:devserver]
use = egg:Paste#http
port = 8000

[app:main]
# Dev mode
use = twod.wsgi
django_settings_module = yourpackage.settings

[app:deploy]
use = main
set debug = False


And insted of running "manage.py runserver", you'd run "paster serve
whatever.ini". Or, run just "./whatever.ini" if you put the following
at the top of the file:

#!/usr/bin/env paster

[exe]
command = serve
reload = true


Then, to deploy the application, instead of setting
DJANGO_SETTINGS_MODULE and importing Django's WSGI handler, you'd do
the following:

from paste.deploy import loadapp
application = loadapp("config:/path/to/whatever.ini#deploy")


That's it. Please stop by our Google Group (2degrees-dev) if you have
any question, since I don't normally keep an eye on this mailing list.

I understand it might seem more complicated, but it's not really
complicated. The problem is the need to bypass Django's handler, which
is required in order to make your application trully interoperable
with WSGI software. But I am 100% confident nothing will break in your
application. If it does (which is very very very unlikely), please
fill a bug report.

HTH,

Gustavo.
http://dev.2degreesnetwork.com

On Feb 10, 3:09 pm, Jari Pennanen  wrote:
> Hi!
>
> I was wondering what is the status of branch branches/soc2009/http-
> wsgi-improvements 
> (http://github.com/django/django/tree/soc2009/http-wsgi-improvements
> )? I'm personally interested one bug it fixes, mainly ticket #2131
> (http://code.djangoproject.com/ticket/2131)
>
> The branch seems to be 6 months old, and this makes me nervous to rely
> on it, if it is not merged to trunk I'm screwed on relying on branch
> that old...

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: WSGI support in Django

[Gustavo Narea]

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.

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:
> On Tue, Oct 27, 2009 at 10:49 PM, Gustavo Narea
> <gustavona...@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 %-)
> 
> --~--~-~--~~~---~--~~
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@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/

--

You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: WSGI support in Django

[Gustavo Narea]

Hello again,

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.


On Wed, 2009-10-28 at 09:58 +, Gustavo Narea wrote:
> Hello, Russell.
> 
> 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.
> 
> 
> On Wed, 2009-10-28 at 08:24 +0800, Russell Keith-Magee wrote:
> > On Tue, Oct 27, 2009 at 10:49 PM, Gustavo Narea
> > <gustavona...@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
-- 
Gustavo Narea.
Software Developer.
2degrees, Ltd.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: WSGI support in Django

[Gustavo Narea]

Hello, Russell.

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.


On Wed, 2009-10-28 at 08:24 +0800, Russell Keith-Magee wrote:
> On Tue, Oct 27, 2009 at 10:49 PM, Gustavo Narea
> <gustavona...@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
-- 
Gustavo Narea.
Software Developer.
2degrees, Ltd.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

WSGI support in Django

[Gustavo Narea]

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. ;-)

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

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---