On 14 mars 2013, at 15:43, Alex Ogier <[email protected]> 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 [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.


Reply via email to