In the meantime, shall we abandon the idea of organizing settings in dictionaries for "purity"? May we add new settings as described here: https://code.djangoproject.com/ticket/22734#comment:22
On Friday, September 5, 2014 12:39:02 PM UTC-4, Russell Keith-Magee wrote: > > > > On Thu, Sep 4, 2014 at 4:39 PM, Carl Meyer <[email protected] > <javascript:>> wrote: > >> On 09/04/2014 05:36 PM, Collin Anderson wrote: >> > I'm trying to think outside the box on settings. >> > >> > If we want to logically group settings together, what if we supported >> > syntax like this? >> > >> > MIDDLEWARE_CLASSES = ( >> > 'django.middleware.clickjacking.XFrameOptionsMiddleware', >> > SecurityMiddleware(content_type_nosniff=True, xss_filter=True), >> > ) >> > >> > It could be a more pythonic way for middleware to have their own >> settings. >> >> Proposals like this generally run afoul of circular import problems. As >> soon as you have people importing parts of Django or their project in >> their settings file, those modules likely import other modules which in >> turn import django.conf.settings, and boom! >> > > Since I'm sitting at the DjangoCon US sprints, and I'm feeling a little > optimistic and crazy, I thought I'd throw this idea out there... > > The other way to resolve this would be to rethink the way Django starts > up. > > Settings like MIDDLEWARE_CLASSES have always struck me as being a little > odd - they're not really settings, they're a way to configure the way code > is executed without actually writing and executing code. The same is true > of things like ROOT_URLCONF, a few of the template loaders and path > specifications, and so on. > > If we were starting green-fields, it seems to me that we wouldn't do it > this way; the Pyramid/Flask approach of doing this sort of thing by > actually defining code would make a lot more sense. Django currently has a > well defined, but opaque startup sequence where settings are loaded and > then the middlware, urlconfs etc are set up. The alternative would be an > explicit startup sequence that constructs the desired middlewares, installs > them into a root urlconf, configures loaders and so on, and then sets the > environment running. > > This should also avoids the circular dependency problem, because anything > that needs to do an import in the settings file would be part of the > configuration process. > > To be clear, I know this would be a huge change. If we went down this > path, we'd need to maintain the old/current way of deploying Django for a > long time. In the interests of getting started quickly, it might even be > desirable to maintain both approaches long term. But having an explicit > startup sequence would allow for complex middleware configuration like this > thread has proposed. I'm just throwing this idea out on the porch to see if > the cat licks it up. > > Yours, > Russ Magee %-) > -- 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/3df38529-9d9c-4828-9f5f-dec033d54d35%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
