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.