la gestión de múltiples archivos settings.py

Question

Duplicar posible:
How to manage local vs production settings in Django?

he logrado implementar con éxito un proyecto Django en del servidor Web Apache con mod_wsgi.

me gustaría algunas recomendaciones sobre cómo gestionar múltiples settings.py archivos. Ahora mismo tengo uno para desarrollo y uno totalmente diferente para producción (con respecto a parámetros DB, localización de contenido estático y cosas por el estilo). Mi archivo settings.py se versiona (no sé si esto es una buena práctica) y desplegarlo 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 múltiples versiones de archivos settings.py?

Answer 1

utilizo 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 todos los ajustes comunes en todos los tipos de servidores .

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

Entonces los otros archivos se parecen un poco (production.py):

DEBUG=False 
TEMPLATE_DEBUG=False 
from _base import * 

En cada uno de estos archivos, me puso en la configuración que sólo se aplican a este tipo de servidor.

Answer 2

django-admin.py/manage.py tanto aceptar una opción --settings=mysite.settings. En desarrollo, puede especificar explícitamente --settings=dev_settings. También puede establecer la variable de entorno E DJANGO_SETTINGS_MODUL en su configuración de Apache.

Personalmente, simplemente NO MARCA en settings.py. En vez puedo comprobar en múltiples archivos de configuración (dev_settings, prod_settings, etc.) y simbólicamente los relacionan con las settings.py lo deseas. De esta manera si simplemente pago y envío mi solicitud no será ejecutable hasta pienso en qué configuración de archivo es apropiado y que en realidad poner archivo de configuración en su lugar.

Otra sugerencia que he oído, pero no me gusta especialmente es tener un settings.py que importa 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á la configuración en realidad sin buscar también anular los valores en un archivo dev_settings.py que puede existir o no.

Answer 3

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

configuración agnósticos ambiente va 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 settings.py en los local_settings apropiadas.py

Answer 4

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