Django
Ajustes
Buscar..
Configuración de la zona horaria
Puedes establecer la zona horaria que usará Django en el archivo settings.py . Ejemplos:
TIME_ZONE = 'UTC' # use this, whenever possible
TIME_ZONE = 'Europe/Berlin'
TIME_ZONE = 'Etc/GMT+1'
Aquí está la lista de zonas horarias válidas
Cuando se ejecuta en un entorno Windows , debe configurarse de la misma manera que la zona horaria del sistema .
Si no quieres que Django use tiempos de datos conscientes de la zona horaria:
USE_TZ = False
Las mejores prácticas de Django requieren el uso de UTC para almacenar información en la base de datos:
Incluso si su sitio web está disponible en una sola zona horaria, sigue siendo una buena práctica almacenar datos en UTC en su base de datos. La razón principal es el horario de verano (DST). Muchos países tienen un sistema de horario de verano, donde los relojes se mueven hacia adelante en primavera y hacia atrás en otoño. Si está trabajando en la hora local, es probable que encuentre errores dos veces al año, cuando ocurren las transiciones.
https://docs.djangoproject.com/en/stable/topics/i18n/timezones/
Accediendo a las configuraciones
Una vez que tenga todas sus configuraciones, querrá usarlas en su código. Para hacerlo, agregue la siguiente importación a su archivo:
from django.conf import settings
Luego puede acceder a su configuración como atributos del módulo de settings , por ejemplo:
if not settings.DEBUG:
email_user(user, message)
Usando BASE_DIR para asegurar la portabilidad de la aplicación
Es una mala idea para las rutas de código duro en su aplicación. Siempre se deben usar direcciones URL relativas para que su código pueda funcionar sin problemas en diferentes máquinas. La mejor manera de configurar esto es definir una variable como esta
import os
BASE_DIR = os.path.dirname(os.path.dirname(__file__))
Luego use esta variable BASE_DIR para definir todas sus otras configuraciones.
TEMPLATE_PATH = os.path.join(BASE_DIR, "templates")
STATICFILES_DIRS = [
os.path.join(BASE_DIR, "static"),
]
Y así. Esto garantiza que pueda transferir su código a diferentes máquinas sin ninguna preocupación.
Sin embargo, os.path es un poco detallado. Por ejemplo, si su módulo de configuración es project.settings.dev , tendrá que escribir:
BASE_DIR = os.path.dirname(os.path.dirname(os.path.dirname(__file__)))
Una alternativa es utilizar el módulo unipath (que puede instalar con pip install unipath ).
from unipath import Path
BASE_DIR = Path(__file__).ancestor(2) # or ancestor(3) if using a submodule
TEMPLATE_PATH = BASE_DIR.child('templates')
STATICFILES_DIRS = [
BASE_DIR.child('static'),
]
Uso de variables de entorno para gestionar la configuración en servidores
El uso de variables de entorno es una forma muy utilizada para configurar la configuración de una aplicación en función de su entorno, como se indica en la aplicación The Twelve-Factor .
Como es probable que las configuraciones cambien entre los entornos de implementación, esta es una forma muy interesante de modificar la configuración sin tener que buscar en el código fuente de la aplicación, así como guardar secretos fuera de los archivos de la aplicación y el repositorio de código fuente.
En Django, la configuración principal se encuentra como settings.py en la carpeta de su proyecto. Como es un simple archivo de Python, puede usar el módulo os de Python de la biblioteca estándar para acceder al entorno (e incluso tener los valores predeterminados adecuados).
settings.py
import os
SECRET_KEY = os.environ.get('APP_SECRET_KEY', 'unsafe-secret-key')
DEBUG = bool(os.environ.get('DJANGO_DEBUG', True) == 'False')
ALLOWED_HOSTS = os.environ.get('DJANGO_ALLOWED_HOSTS', '').split()
DATABASES = {
'default': {
'ENGINE': os.environ.get('APP_DB_ENGINE', 'django.db.backends.sqlite3'),
'NAME': os.environ.get('DB_NAME', 'db.sqlite'),
'USER': os.environ.get('DB_USER', ''),
'PASSWORD': os.environ.get('DB_PASSWORD', ''),
'HOST': os.environ.get('DB_HOST', None),
'PORT': os.environ.get('DB_PORT', None),
'CONN_MAX_AGE': 600,
}
}
Con Django, puede cambiar la tecnología de su base de datos, de modo que puede usar sqlite3 en su máquina de desarrollo (y eso debería ser un buen valor predeterminado para comprometerse con un sistema de control de origen). Aunque esto es posible no es aconsejable:
Los servicios de respaldo, como la base de datos de la aplicación, el sistema de colas o el caché, es un área donde la paridad dev / prod es importante. ( La aplicación de los doce factores - Paridad de desarrollo / prod )
Para utilizar un parámetro DATABASE_URL para la conexión a la base de datos, consulte el ejemplo relacionado .
Usando múltiples configuraciones
El diseño de proyecto predeterminado de Django crea un solo settings.py . Esto suele ser útil para dividirlo así:
myprojectroot/
myproject/
__init__.py
settings/
__init__.py
base.py
dev.py
prod.py
tests.py
Esto le permite trabajar con diferentes configuraciones según esté en desarrollo, producción, pruebas o lo que sea.
Al pasar del diseño predeterminado a este diseño, la settings.py original.py se convierte en settings/base.py Cuando todos los demás submódulos "subclase" settings/base.py comenzando con from .base import * . Por ejemplo, aquí es cómo se ve la settings/dev.py :
# -*- coding: utf-8 -*-
from .base import * # noqa
DEBUG = True
INSTALLED_APPS.extend([
'debug_toolbar',
])
EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend'
INTERNAL_IPS = ['192.168.0.51', '192.168.0.69']
Alternativa # 1
Para que django-admin comandos de django-admin funcionen correctamente, tendrá que configurar la variable de entorno DJANGO_SETTINGS_MODULE (que por defecto es myproject.settings ). En desarrollo, lo establecerá en myproject.settings.dev . En producción, lo establecerá en myproject.settings.prod . Si usa un virtualenv, lo mejor es establecerlo en su script postactivate :
#!/bin/sh
export PYTHONPATH="/home/me/django_projects/myproject:$VIRTUAL_ENV/lib/python3.4"
export DJANGO_SETTINGS_MODULE="myproject.settings.dev"
Si desea usar un módulo de configuración que no es señalado por DJANGO_SETTINGS_MODULE por una vez, puede usar la opción --settings de django-admin :
django-admin test --settings=myproject.settings.tests
Alternativa # 2
Si quieres dejar DJANGO_SETTINGS_MODULE en su configuración por defecto ( myproject.settings ), puede simplemente decir la settings módulo de la configuración que se cargue mediante la colocación de la importación en su __init__.py archivo.
En el ejemplo anterior, el mismo resultado se podría lograr al tener un __init__.py configurado para:
from .dev import *
Usando múltiples archivos de requerimientos
Cada archivo de requisitos debe coincidir con el nombre de un archivo de configuración. Lea Uso de configuraciones múltiples para más información.
Estructura
djangoproject
├── config
│ ├── __init__.py
│ ├── requirements
│ │ ├── base.txt
│ │ ├── dev.txt
│ │ ├── test.txt
│ │ └── prod.txt
│ └── settings
└── manage.py
En el archivo base.txt , coloque las dependencias utilizadas en todos los entornos.
# base.txt
Django==1.8.0
psycopg2==2.6.1
jinja2==2.8
Y en todos los demás archivos, incluya las dependencias base con -r base.txt y agregue las dependencias específicas necesarias para el entorno actual.
# dev.txt
-r base.txt # includes all dependencies in `base.txt`
# specific dependencies only used in dev env
django-queryinspect==0.1.0
# test.txt
-r base.txt # includes all dependencies in `base.txt`
# specific dependencies only used in test env
nose==1.3.7
django-nose==1.4
# prod.txt
-r base.txt # includes all dependencies in `base.txt`
# specific dependencies only used in production env
django-queryinspect==0.1.0
gunicorn==19.3.0
django-storages-redux==1.3
boto==2.38.0
Finalmente, para instalar dependencias. Ejemplo, en dev env: pip install -r config/requirements/dev.txt
Ocultar datos secretos usando un archivo JSON
Al usar un VCS como Git o SVN, hay algunos datos secretos que nunca deben ser versionados (ya sea que el repositorio sea público o privado).
Entre esos datos, se encuentra la configuración SECRET_KEY y la contraseña de la base de datos.
Una práctica común para ocultar estas configuraciones del control de versiones es crear un archivo secrets.json en la raíz de su proyecto ( gracias a la idea ) " Two Scoops of Django " :
{
"SECRET_KEY": "N4HE:AMk:.Ader5354DR453TH8SHTQr",
"DB_PASSWORD": "v3ry53cr3t"
}
Y .gitignore a tu lista de ignorados ( .gitignore para git):
*.py[co]
*.sw[po]
*~
/secrets.json
Luego agregue la siguiente función a su módulo de settings :
import json
import os
from django.core.exceptions import ImproperlyConfigured
with open(os.path.join(BASE_DIR, 'secrets.json')) as secrets_file:
secrets = json.load(secrets_file)
def get_secret(setting, secrets=secrets):
"""Get secret setting or fail with ImproperlyConfigured"""
try:
return secrets[setting]
except KeyError:
raise ImproperlyConfigured("Set the {} setting".format(setting))
Luego llene la configuración de esta manera:
SECRET_KEY = get_secret('SECRET_KEY')
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgres',
'NAME': 'db_name',
'USER': 'username',
'PASSWORD': get_secret('DB_PASSWORD'),
},
}
Usando un DATABASE_URL del entorno
En sitios de PaaS como Heroku, es habitual recibir la información de la base de datos como una única variable de entorno de URL, en lugar de varios parámetros (host, puerto, usuario, contraseña ...).
Hay un módulo, dj_database_url , que extrae automáticamente la variable de entorno DATABASE_URL a un diccionario de Python apropiado para inyectar la configuración de la base de datos en Django.
Uso:
import dj_database_url
if os.environ.get('DATABASE_URL'):
DATABASES['default'] =
dj_database_url.config(default=os.environ['DATABASE_URL'])
