Does it matter?
A simple Flask application, hello.py
:
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.