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 <[email protected]> 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 <[email protected]> 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 >> <[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. >> >> > > -- > 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.
