

UWSGI is a fast (pure C), self-healing, developer-friendly WSGI server - cd34
http://projects.unbit.it/uwsgi/

======
tvon
From the linked page:

    
    
      Why ? There are already mod_wsgi, flup and lot of protocols (fastcgi, scgi...). 
      Is this faster or simpler to configure ?
    
      Stop acting as a Rails user ! Deploy of python web applications is not a problem.
    
      No need of ultra-hypeous next-fu*king-useless almost-working deploy technology.
    
      The challenge in the python-world is now "features", uWSGI is a feature rich
      application, developer (and administrator/security paranoid/business environments) 
      friendly. Stop.
    
      Other deploy systems, works very well, this one does only more things.

~~~
ncarlson
Why do some programmers feel the need to piss on other people's projects?

------
moe
Much needed. We pythonistas are still waiting for a deployment option as slick
as ruby passenger.

I'd prefer to see this wrapped up as an nginx-module and seems they have that
on their todo-list - awesome!

~~~
old-gregg
Slick? Passenger spawns additional processes that require maintenance. I was
always envy of Python's mod_wsgi - can it get even better? What don't you like
about mod_wsgi?

~~~
moe
As far as I know (correct me if I'm wrong) passenger is maintenance free.
Anything else wouldn't make much sense anyways. It maintains a pool of workers
and distributes load over them, just as it should be.

mod_wsgi for apache seems to do the same so I should have been more specific:
I'm still waiting for a proper mod_wsgi for _nginx_. The nginx mod_wsgi is not
the same as the apache version. It has some very unfortunate problems which
effectively rule it out for production use:

[http://blog.dscpl.com.au/2009/05/blocking-requests-and-
nginx...](http://blog.dscpl.com.au/2009/05/blocking-requests-and-nginx-
version-of.html)

~~~
kblessinggr
I was actually talking to a developer awhile back, the conversation resulted
in him actually updating the Ubuntu repository for Nginx's mod_wsgi to be
updated to mod_wsgi 2.5 (as opposed to 1.0) and making it have choices of
using Python 2.4 thru 2.6 via variants. But even then it was barely stable on
Nginx 0.7.* and un-buildable on Nginx 0.8.*.

At the moment the most stable version of Nginx to run mod_wsgi with is the
legacy 0.6.+, the original author ported it during the 0.5 release.

Performance and integration wise, Passenger excelled over trying to hack the
mod_wsgi plugin into working. And as you said there are too many bugs to be
effectively used in a production environment.

Once Passenger is compiled, it only requires two lines in the Nginx
configuration to enable a Python WSGI application, and its no more heavy on
resources than Nginx itself. You do of course have to restart Nginx (which in
effect restarts Passenger) if you change or add a web application, but thats
about the only hard part. Passenger even builds and installs Nginx for you, so
not sure where the high maintenance is at.

~~~
moe
_You do of course have to restart Nginx (which in effect restarts Passenger)
if you change or add a web application_

Actually depending on your web framework you don't even have to do that.
Werkzeug and others support code-reloading.

By the way I had a talk with a passenger developer yesterday and the WSGI
support seems to be stabilizing. I was told that dreamhost is already using it
in production - so it's undocumented but functional.

------
jerome_etienne
they claims to be fast. do they provide bench compare with alternatives ?

------
illumen
Looks interesting. I like that at least one real ISP is using it... it gives
me hope that one day it will spread to be a good solution for python apps on
cheap web hosts.

Also it is good to have a couple of different python extensions for apache. It
keeps them all on their toes.

I'm not sure the GPL licence makes sense for this project though. It means
that to use it, people have to use the GPL for their web apps... or
pay/negotiate a different licence. Well, maybe getting people to pay for it is
their intention.

The protocol uses a 16bit length headers... meaning it will fail for big
payloads. That turned me off investigating it out any further. However it is
likely not a problem.

~~~
dryicerx
Even though uWSGI's source is GPL, that doesn't mean your web apps need to be
GPL, that would make this completely useless (same way your editor is GPL but
the code you write with it does not need to be). This would apply if you
decide somehow bundle the uWSGI's source within your application for whatever
reason.

~~~
illumen
hi,

If your app links to a GPL app, then your app is most likely covered by the
GPL.

There are not copyright notices in all the files... but it looks like you are
supposed to import a GPL module into your python program... thus the GPL is in
effect. The uwsgi.c python module has a GPL copyright notice.

If your python web app talks to the server over a socket... then that is a
different thing, and the GPL does not apply.

So I'm not sure how it applies in this case where your app talks to it over a
socket. Note the README in the project is empty... and there is not much other
documentation which I could find that explains exactly how this is to be used.

~~~
chipsy
The regular GPL contains a distribution loophole which excludes your use case.
That case is covered by AGPL:
<http://en.wikipedia.org/wiki/Affero_General_Public_License>

------
jokull
Anyone had a go with this?

