Gestión de múltiples archivos settings.py

Posible duplicado:
¿Cómo administrar la configuración de producción local vs en Django?

He logrado implementar con éxito un proyecto de Django en el servidor web de Apache con mod_wsgi .

Me gustaría algunas recomendaciones sobre cómo administrar múltiples archivos settings.py . Ahora mismo tengo uno para desarrollo y otro totalmente diferente para producción (en relación con los parámetros de DB, la localización de contenido estático y cosas por el estilo). Mi archivo settings.py está versionado (no sé si es una buena práctica) y lo implemento con algo como:

 $ hg archive myproject.tbz2 $ cd /path/of/apache/web/project/location $ bzip2 -db /home/myself/myproject/myproject.tbz2 | tar -xvf - 

Está funcionando bien. Pero me encuentro manipulando múltiples archivos settings.py .

Supongo que mi pregunta es: ¿cuáles son las mejores prácticas al implementar DJANGO PROJECTS con respecto a las múltiples versiones del archivo settings.py ?

    Yo uso un módulo de configuración que no es un solo archivo:

     settings/ __init__.py _base.py _servers.py development.py production.py testing.py 

    El archivo __init__.py es simple:

     from _servers import get_server_type exec("from %s import *" % get_server_type()) 

    El archivo _base.py contiene todas las configuraciones comunes en todos los tipos de servidores.

    El archivo _servers.py contiene una función get_server_type() que usa socket.gethostname() para determinar qué tipo de servidor es la máquina actual: devuelve el development , la production o las testing .

    Luego los otros archivos se ven un poco como ( production.py ):

     DEBUG=False TEMPLATE_DEBUG=False from _base import * 

    En cada uno de estos archivos, puse la configuración que solo se aplica a este tipo de servidor.

    El truco que parece ser el más común es mantener un archivo settings.py y local_settings.py (uno para cada entorno).

    La configuración independiente del entorno se encuentra en settings.py y en la parte inferior del archivo, importará desde local_settings.py

     try: from local_settings import * except ImportError: pass 

    Puede anular cualquier configuración de settings.py en el local_settings.py apropiado

    django-admin.py / manage.py ambos aceptan una opción --settings=mysite.settings . En desarrollo, podría especificar explícitamente --settings=dev_settings . También puede configurar la variable de entorno DJANGO_SETTINGS_MODUL E en su configuración de apache.

    Personalmente, simplemente no verifico settings.py. En su lugar, registro varios archivos de configuración (dev_settings, prod_settings, etc.) y simbólicamente los vinculo a settings.py como se desee. De esta manera, si simplemente pago mi aplicación, no se podrá ejecutar hasta que piense qué archivo de configuración es el adecuado y, de hecho, puse ese archivo de configuración en su lugar.

    Otra sugerencia que he escuchado pero que no me gusta particularmente es tener un settings.py que importe dinámicamente un dev_settings.py si existe. Si bien esto puede ser más conveniente, me preocuparía que sea más difícil leer settings.py y saber cuál será realmente la configuración sin tener que buscar también valores de reemplazo en un archivo dev_settings.py que pueden o no existir.

    Mi forma preferida es cargar un archivo ini separado utilizando ConfigParser, basado en una única configuración o variable de entorno. De todos modos, en la wiki de django hay muchas opciones diferentes descritas: http://code.djangoproject.com/wiki/SplitSettings