Sune Kirkeby wrote:
On 10/11/05, hugo <[EMAIL PROTECTED]> wrote:
Actually I think a better way might just be to change django so that it
doesn't pull the DJANGO_SETTINGS_MODULE from the environment, but use a
django.settings_module from the WSGI environment - that can be handled
distinctly for every application. Currently, Django pulls it from
os.environ, so WSGI overrides won't kick in.
There are two problems. The first problem is that django.conf.settings
is magically populated, but only the first time it is imported.
That can be handled easily enough by the DispatchingConfig/threadlocal
technique, but...
The other problem is that a common idiom in Django is
from django.conf.settings import SOME_SETTING
again this only pulls SOME_SETTING the first time it is imported,
so a lot of code would need to be changed, or all the attributes
of django.conf.settings would have to be magical proxy-objects.
Otherwise a lot of code would never see the different settings.
...only if the settings are loaded on an as-needed basis. I.e.,
anything at the module level has to be configuration agnostic. Besides
threadlocal configuration, you can use other threadlocal objects to
achieve this -- for instance, SQLObject uses a threadlocal connection
descriptor, to override a class variable globally based on
configuration, but without being particularly attached to any
configuration mechanism.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
