Yeah, split by role is what I have done. settings/default.py (absolute necessities) settings/deploy.py (inherits default.py & adds production specifics) settings/debug.py (inherits deploy.py & overwrites debug stuff) settings/test.py (inherits deploy.py & overwrites test specific) settings/external.py (holds aws, google, and other social keys)
The above is coupled with: bin/debug.py (= manage.py on development server) bin/deploy.py (= manage.py on production server) bin/test.py (= manage.py on integration server) This has been working very well for me. No loose files, everything has a directory to live in. Very easy to manage. Val On Wed, Mar 13, 2013 at 9:32 PM, Russell Keith-Magee <[email protected]> wrote: > > On Thu, Mar 14, 2013 at 1:08 AM, Alex Ogier <[email protected]> wrote: >> >> I find the value of separate settings modules is not splitting them by >> topic, but overriding them in specific contexts, like staging, production >> and development. Your implementation (and, I think, any solution that >> compiles multiple settings modules independently) don't have a way to >> specify orderings in a non-magical way. That's why I prefer explicitly >> importing some common settings into one module and overriding them >> piecemeal. The Zen of Python says "Explicit is better than implicit" and I >> think that is the case here. Packages provide settings and reasonable >> defaults. If you want to modularize them, you are free to do so yourself. I >> think composing settings internally is just added complexity for little >> benefit. > > > I agree with Alex. > > Splitting settings files in the way you've described in your patch doesn't > strike me as something that solves a problem that actually exists in > practice. Settings files aren't *that* long, and to the extent that splits > are needed, they're based on roles, not content -- you need "production" > settings, not "template" settings. > > Even if you did want to break out settings into multiple files, a master > file with "from template_settings import *" strikes me as a lot better > approach than a settings gathering process -- and that requires no extra > code in Django. > > 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?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
