About twod.wsgi

twod.wsgi has only one goal, which is to bring WSGI support to Django to the same level as in the other modern Python frameworks. We tried it to implement these improvements at the core of Django, but unfortunately that is not going to happen for the time being.

If we succeed and make Django developers realise how critical interoperability with and reusability of existing 3rd party software are, we may see these improvements in Django 1.3. And you can do your bit by supporting twod.wsgi.

This is another project brought to you by 2degrees Limited.

Getting help

Keep in mind that twod.wsgi is a thin integration layer, so if you have questions about the 3rd party software mentioned in the manual, it’s best to use the support channels for that particular project.

For questions about WebOb, WebTest, PasteDeploy, PasteScript and Paste itself, use the paste-users mailing list. Nose has its nose-users mailing list and the preferred support channel for Buildout is Python’s Distutils-SIG. Python’s Web-SIG is the right place for queries about WSGI in general.

For questions directly related to twod.wsgi or if you’re not sure what’s the right place to ask a given question, please use our 2degrees-floss mailing list.

Supporting twod.wsgi

If you’ve found this project useful, please help us spread the word about it in the Django community!

You may also consider voting for it on Ohloh and/or Freshmeat.


We’ll only implement the features we’re going to use, but if there’s something you’re missing, we’d be pleased to apply patches for the features you need, as long as:

  • They are PEP 8 and preferably 257 compliant.
  • There are unit tests for the new code.
  • The new code doesn’t break existing functionality.

Please go to our development site on GitHub to get the latest code, fork it (and ask us to merge them into ours) and raise issues.

twod.wsgi versus...

There are a few projects with similar aims and although twod.wsgi is the newest of all, it’s the only one that is both comprehensively tested and fully documented. We’re also not aware of any production site using one of them (there may be, though), while twod.wsgi has been in use at least in a high-traffic Web site.

They all aim to implement different things. twod.wsgi implements them all, and more.


It only implements a PasteDeploy application factory which sets the DJANGO_SETTINGS_MODULE variable, but doesn’t pass the options on to the Django settings. It’s not under active development.

However, if that’s all you want, it should be good enough. If you decide to switch to twod.wsgi later, it’d be a piece of cake.


It’s an unfinished Django branch and it’s not under active development.


It only allows you to run WSGI applications from Django views and also run a set of Django views as an standalone WSGI application. We tried to join forces and contribute to that project instead of starting this one, but never got a response back.

We’re also not sure if it’s usable:

  • When you run a WSGI application, the path that has been consumed by the view is not moved to the SCRIPT_NAME. Every embedded application should misbehave.
  • Authentication information is not passed on to the embedded application (i.e., REMOTE_USER).
  • We don’t see the point in running Django views as WSGI applications. It’s also inconvenient because no Django middleware gets run, neither do routines set by Django’s WSGI handler. [1]

Although these may be bugs, not the intended behaviour.



If you really wanted to collect individual views into an standalone Django-powered WSGI application, a safer approach would be to:

  1. Define the URLConf for that application (say, at your_package.urls_subset).
  2. Extend the existing PasteDeploy configuration for the main/complete application, like this:
use = existing_main_application
ROOT_URLCONF = your_package.urls_subset
  1. Use the “standalone_subset” version of your application:

    from paste.deploy import loadapp
    smaller_app = loadapp("config:/path/to/config.ini#standalone_subset")