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 <russ...@keith-magee.com> wrote: > > On Thu, Mar 14, 2013 at 1:08 AM, Alex Ogier <alex.og...@gmail.com> 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 django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
