I like this technique to organize Django's settings: http://stackoverflow.com/questions/88259/how-do-you-configur...

Example: https://github.com/JimDabell/lojban-website/tree/master/lojb...

We just do the inverse. In a local_settings.py we import settings - then set DJANGO_SETTINGS_MODULE=path.to.local_settings

This is by far the simplest and best way I've found. This also allows me to remove manage.py and use django-admin.py. I just set DJANGO_SETTINGS_MODULE in the virtualenv's postactivate hook file.

I like Django quite a bit, but the mind boggles at how many developer hours have been spent trying to organize settings, or deal with migrations, or setting up deployment scripts, or coming up with a sensible project layout.

I mean, doesn't everyone have to solve these problems for almost every project? Django seems to try too hard not to make decisions for you, when it would make more sense to make easily ignored decisions.

> how many developer hours have been spent trying to organize settings, or deal with migrations, or setting up deployment scripts, or coming up with a sensible project layout

Countless. Django prefers configuration over convention. I think it's because there is too much focus on the reusable apps concept. It would be great if it was a little bit the other way around.

Are there still issues with migrations, or are you referring to Django's past? South migrations work smoothly for me.

The fact that you have to install South to begin with is an issue, IMHO.

Django had a project accepted to Google Summer of Code 2011 to get some schema migration love into core, so the future looks good, but if you ask me 'pip install south' isn't that much of an issue.

This should not be innovative to anybody who knows Python, and how __init__.py works. The post may as well be a link to http://docs.python.org/tutorial/modules.html#packages

> No, it’s not possible. And don’t try from settings import INSTALLED_APPS, it won’t work.

Dang, I wish someone had told me that. I use it all the time, and it works for me just fine. No circular reference errors or anything else of the sort.

Yea, the error author was seeing is a beginner one, because he was importing local_settings in settings, and settings in local_settings. Most circular import issues are a little more interesting.

Simple but common: http://google.com/codesearch?q=%22from+local_settings+import...

Still keep wondering how to fix settings.py so that its more usable and so that we could keep more settings in the database, guess it will never happen to everyones agreement..

I'm a big fan of extending the settings_local pattern to make it possible to add to lists.. for that I use this snippet to be able to define things like 'EXTRA_INSTALLED_APPS' in my local settings.. Super handy.

https://gist.github.com/948855

This is a bad idea on so many levels. You should always talk to the most specific version of your settings rather than have the super generic one try to add extra stuff from another module that it loaded.

Sorry, I'm not getting it... but I'd love some elaboration on where this causes problems. It's also worth mentioning (you'll note the if DEBUG bit) that this is only something we use locally to make it easy to toss stuff like the debug toolbar in, etc.