Yeah, settings is more about the environments than the framework. There is not a single solutions that can make everyone happy. I'd say whatever works for you is the best solution for you.
With that said, I also agree that a few good examples would be very beneficial to people new to Django. Val On Thu, Mar 14, 2013 at 10:43 AM, Alex Ogier <alex.og...@gmail.com> wrote: > I think the important point is that all of these techniques for constructing > settings are done without the help of Django (and in fact *should* be done > without the help of Django, because some parts of Django expect to import a > settings module that isn't under construction). I don't know if there is a > good way to document these practices -- it's not an easily searchable topic, > and more than a single settings.py is just added confusion for little > benefit until you need to care about deploying to multiple contexts (it's > not good tutorial material). Maybe somewhere in the how-tos on deployment we > could write up some good practices for managing settings in multiple > contexts -- that would be more welcome than code in Django core, I think. > Midterms end today for me, so maybe I will try writing up some of the > practices that make managing settings easier for me later tonight. > > Best, > Alex Ogier > > > On Thu, Mar 14, 2013 at 9:16 AM, Val Neekman <v...@neekware.com> wrote: >> >> 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. >> >> > > -- > 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.
