Decentralizing settings.py

[Joshua "jag" Ginsberg]

We're developing a great number of utility applications, each of which
introduce their own configurable settings specific to the individual
application. As a result, settings.py gets *cluttered* with tons of
options and documentation and becomes incredibly difficult to read. So I
patched django/conf/__init__.py to try to decentralize
application-specific settings.

The resulting patch, submitted to Trac as #5049, does the following:

* Applications can provide a settings.py file in their application
directory. This file will be parsed exactly as settings.py would be,
only observing ALL_CAPS attributes. These attributes will be made
available at django.conf.settings.*appname*.*attribute*

* Since it is important that each project be able to override settings,
these settings can be overridden per-project by creating a subfolder in
the project called app_settings and placing a file *appname*.py in it
with the local overrides.

So if proj.app.settings says that FOO='bar' and BLAH='blech', and
proj.app_settings.app says that FOO='baz', django.conf.settings.app.FOO
is 'baz' and django.conf.settings.app.BLAH is 'blech'.

I'd welcome any feedback on this patch. Thanks!

-jag (j00bar on #django)

[Jacob Kaplan-Moss]

Hi Joshua --

On 8/2/07, Joshua jag Ginsberg <dja...@flowtheory.net> wrote:
> I'd welcome any feedback on this patch. Thanks!

It's some good code, but this idea has come up in the past (search the
archives) and we've decided against it.

The basic concept is this: since settings are just Python code, you're
free to deal with them however you want. For advanced uses, things
like what you've done is very useful, but for the simple case it's
crushing a mosquito with a jackhammer. We'd prefer to keep the default
case simple and leave stuff like this up to third-party code.

Jacob