Does it matter?
A simple Flask application,
from flask import Flask helloapp = Flask(__name__) @helloapp.route('/') def hello_world(): return "Hello World"
Compared with the simple WSGI Hello, world application, we
just have to add a
--callable argument which specifies
the name of our Flask application (
helloapp in this example).
$ uwsgi --scgi-socket /tmp/helloSCGI.s --wsgi-file hello.py --callable helloapp ...
When using a
.ini file for the uWSGI configuration, add
the following line:
callable = helloapp
A simple CherryPy application,
hello.py, that provides a
standard WSGI interface:
import cherrypy class HelloWorld(object): def index(self): return "Hello World" index.exposed = True def application(environ, start_response): cherrypy.tree.mount(HelloWorld(), '/') return cherrypy.tree(environ, start_response)
Because the standard callable (
application) is provided,
uWSGI usage is just as with our original WSGI Hello, world.
First, credit is due to others for most of this example Django app:
I'm guessing that this is not what you expected to see:
# Thanks to Julia Elman and Mark Lavin's article at # http://programming.oreilly.com/2014/04/simplifying-django.html # for showing near-minimal bits, which I then uglified for my own # purposes. import sys from django.conf import settings from django.conf.urls import patterns from django.http import HttpResponse from django.utils.crypto import get_random_string settings.configure( # In a real app this should be a fixed value; call get_random_string() in the # shell and plug the result in here. SECRET_KEY=get_random_string(50, 'abcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*(-_=+)'), ROOT_URLCONF=sys.modules[__name__], ) def index(request): return HttpResponse('Hello world') urlpatterns = patterns('', (r'^$', index), ) from django.core.wsgi import get_wsgi_application application = get_wsgi_application()
Modern Django (
django-admin.py startproject to be specific)
creates a WSGI wrapper (
project/wsgi.py), so controlling
your Django app with uWSGI is basically a matter of telling it about the
WSGI application. (My application defines the WSGI object in the sole source
file instead of using a separate
wsgi.py.) Compared with earlier
examples, we're more likely to need some uWSGI configuration that we didn't
happen to need earlier. In my case, I have Django installed in a particular
virtualenv, and my Django app will fall over without being able to
find any interesting imports if the
virtualenv isn't activated. Below you see the use of virtualenv
in a uWSGI configuration file:
[uwsgi] pidfile = /tmp/hello-http-tcp.pid daemonize = /tmp/uwsgi.log http-socket = 127.0.0.1:2000 wsgi-file = hello.py virtualenv = /home/trawick/envs/FastCGI master = true processes = 4 threads = 2 uid = daemon gid = daemon
virtualenv is the only setting I needed in my environment for
Django, and it isn't even specific to Django.
It should simply be a matter of identifying the WSGI object which can be used by uWSGI to interface with the application.