I agree with you, but I think the use case is "that small, 3-template page I want as a quick interface", and this fits the use case perfectly. It usually takes quite a bit of time to set up a Django project (with all the boilerplate), and something like this makes it much, much faster.

Two thumbs up, from me.

I like the Services idea. Django's settings file is the weakest link in the framework. It's easy to roll your own settings apps if all you need to configure is your own code. But that just makes things more complicated when you are integrating other apps.

I've tried a few different apps designed to move settings into the database. None of them have worked very well. This area of Django is still ripe for some killer app to become a defacto standard.

why not just use multiple layered settings files?

in .... settings.py put

from local_settings.py import *

at the bottom

then have

local_settings.dev.py local_settings.prod.py local_settings.release.py

that you copy to local_settings.py depending on the situation.

It's less painful if you invert those files. For example, create settings/defaults.py, then in settings/dev.py, import * from defaults and override what you need to. Set DJANGO_SETTINGS_MODULE appropriately. You'll thank me when you're adding dev-only apps, middlewares, etc. and can say INSTALLED_APPS = INSTALLED_APPS + [...].

This so much. You should be setting DJANGO_SETTINGS_MODULE in your uwsgi config or in your virtualenv postactivate for dev.

I already do that. I have a common_settings.py, a dev_settings.py, and a local_settings.py. That's not really the use case I am speaking of.

First, it still makes you put all application config into a single config file (considering that even if you "inherit" settings from a common file, it's 100% equivalent to having one big settings file).

Second, you cannot change these settings in-app. They are hard-coded.

If it's not already supported, it shouldn't be difficult to make a Django process respond to the HUP signal by reloading it's settings. That's how Postgres does it.

Don't do this, do:

* settings/base.py * settings/production.py * settings/local.py

settings/base would have your "common" settings, settings/local.py could be as simple as from .settings.base import

Or better, have a folder called local_settings with an __init__.py empty file in (making it a package) and then just drop your custom settings there

something like this:

http://tech.yipit.com/2011/11/02/django-settings-what-to-do-...

Took the comment right out of my brain. Looks cool and very novel, bound to be an incredibly leaky abstraction though. Doesn't take away from the novelty/coolness though.

I agree. Great idea in all but Django already is so batteries included, I don't think we need to take it down even further from what it is.