Yup, that works. The issue is that most users never explicitly call django.setup(), so they need to know how to modify manage.py and wsgi.py to do
conf = MyProjectConfig() django.setup(conf) <something here> In the case of wsgi.py this isn't too obtuse, but django.setup() is here - https://github.com/django/django/blob/master/django/core/management/__init__.py#L310 for management commands. Not the easiest place to customise! On 5 September 2014 22:00, Carl Meyer <[email protected]> wrote: > On 09/05/2014 02:54 PM, Marc Tamlyn wrote: > > I like the idea Russ - from a brief peruse of the code base it's > > apparently to me how disparate the handling of various "setup" settings > > is throughout the codebase. For example: > > > > INSTALLED_APPS is handled by django.setup() and Apps.populate() (cached > > attribute) > > MIDDLEWARE_CLASSES is handled by BaseHandler.setup_middleware() (done > > once and cached) > > ROOT_URLCONF is handled by BaseHandler.get_response() (done every > request) > > DATABASES is handled by ConnectionHandler (cached property) > > DATABASE_ROUTERS is handled by ConnectionRouter (cached attribute) > > TEMPLATE_LOADERS is handled by find_template() (saved in a global) > > CACHES is handled by CacheHandler (saved in a threading.local()) > > > > etc. > > > > Perhaps there is an interesting possibility here to move some of these > > disparate "inspect settings, import or configure some stuff and store it > > for the duration of the process" onto a "global" object - something like > > ProjectConfig. It could have methods (cached properties?) like > > .get_middleware_classes() which would return the imported, configured > > middleware classes. > > I like all this. > > > We then (dun dun duuuun) introduce a setting > > PROJECT_CONFIG = 'django.project.ProjectConfig' which you can then set > > yourself if you want to do a more procedural approach. > > But I think this may be backwards; I prefer the idea of creating a > ProjectConfig yourself (via any method you like, you may not need to use > a settings module at all; you could totally get rid of > DJANGO_SETTINGS_MODULE if you want) and passing it as an optional > argument to django.setup(). > > Carl > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/540A2456.80601%40oddbird.net > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwjO1Hd%3DmKkvdUuUCN2Sr%2BHM-PY%3De5u8fqMGL5xY4jGNSwBBw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
