Lazy test loading to deal with conflicting django settings

At work I have a bunch (ok, 3) different django projects in the same big code tree. Yes, I know we should split them up, thanks for pointing that out. Anyway, we are running python unit tests using the trial testrunner from twisted, because it's very nice and we also have some twisted servers in this same code tree.

I have a problem with Django settings. There are some conflicting settings in the settings file used by different Django servers. The solution seems easy - run tests for each Django server in a separate subprocess. The excellent subunit library should do just the trick, it even has IsolatedTestSuite and IsolatedTestCase classes that take care of forking and running in a separate process.

Except this doesn't work. Because when python modules are imported for test discovery, they also indirectly end up importing django.settings, and when the IsolatedTestSuite forks to run tests in a separate subprocess, that subprocess inherits the already polluted python environment that has the (sometimes wrong) django.settings imported already.

I am convinced that this must be solvable, but have been banging my head against it for a while and don't understand unittest discovery well enough to solve it. I've created a self-contained little example that demonstrates the problem in isolation here: https://code.edge.launchpad.net/~statik/+junk/subunit-demo/

I will gladly endure your taunts if you teach me a solution.