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.
