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.
