But I don't have a simple WSGI Hello, world! application

Does it matter?

I have Flask!

A simple Flask application, hello.py:

from flask import Flask
helloapp = Flask(__name__)

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

I have CherryPy!

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.

I have Django!

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

    # In a real app this should be a fixed value; call get_random_string() in the 
    # shell and plug the result in here.
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:

pidfile = /tmp/hello-http-tcp.pid
daemonize = /tmp/uwsgi.log
http-socket =
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.

I have _______!

It should simply be a matter of identifying the WSGI object which can be used by uWSGI to interface with the application.