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.
