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.
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?
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:
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.
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.
Why do you think those additional processes require maintenance? Phusion Passenger maintain them automatically without the sysadmin having to do anything. Even if Apache crashes they'll clean up themselves gracefully.
Course when it comes to webservers such as NGinx, implementations of mod_wsgi are far outdated and not compatible with the last three major releases of the webserver. As such your practical choices for deploying Python (WSGI) applications via NGinx is to use either proxy_pass to a local self-served wsgi application, or Phusion Passenger. The latter being far more feasible.
Thanks gduffy for linking my Nginx + Passenger + Python article, never new this site existed.
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.
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.
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.
Yes, it is a GPL module they want you to load. On the other hand the protocol is itself is so simple, you can write your own implementation of the wsgi module in 15 min. and stop worrying about that. (without looking at their python_wsgi source of course)
