On 14 mars 2013, at 15:43, Alex Ogier <alex.og...@gmail.com> wrote: > 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.
Django leaves settings organization up to each developer because requirements vary widely from one project to another and because it's a very easy problem. In other words, it's the perfect topic for bikeshedding. This wiki page lists a few common patterns: https://code.djangoproject.com/wiki/SplitSettings Jannis wrote https://github.com/jezdez/django-configurations and it's a solid technique, even though using classes for settings offends my aesthetic sense ;-) Of course, my own take on this matter is a hundred times more offensive: http://www.youtube.com/watch?v=tXyenP18iUg#t=1830s If you want to work on a patch, I would suggest to extend docs/topics/settings.txt as follows: 1 - explain that different environments or sites need different settings; 2 - present 2 or 3 well-known techniques, probably chosen among these: - from .local_settings import * - readthedocs.org's or djangoproject.com's technique — it's the same - an advanced modularization technique, like django-configurations, Transifex' technique, or my talk - configure everything through environment variables (I'm not aware of a standard best practice, if there's one and it isn't in this list, include it!) 3 - remind the reader to keep dev & prod settings as similar as possible We should keep this short, and take care not to be prescriptive, because the right solution really depends on the context of each project. -- Aymeric. -- 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.
