Settings.py

  
29 de Septiembre de 2014   0  

Sin duda todos los que programamos en django conocemos este importante archivo, en él podemos configurar todo lo relacionado con nuestro proyecto en curso.

 

Cuando generamos un nuevo proyecto obligatoriamente siempre nos trae uno, en este caso me generé un proyecto demo, quedando de la siguiente manera:

site

Podemos observar el archivo settings.py y, como ya dije anteriormente, aquí se encuentran todas las configuraciones que podemos agregar o modificar para nuestro proyecto; su contenido para la versión 1.7 de django es más corto que en sus versiones anteriores:

 Settings.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
"""
Django settings for demo project.
 
For more information on this file, see
 
For the full list of settings and their values, see
"""
 
# Build paths inside the project like this: os.path.join(BASE_DIR, ...)
import os
BASE_DIR = os.path.dirname(os.path.dirname(__file__))
# Quick-start development settings - unsuitable for production
 
# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = '!3p5@#!j^fz$6l##cwd6l43&xu#dfb5zu5=#mxd4&s7_azl+8^'
 
# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = True
 
TEMPLATE_DEBUG = True
 
ALLOWED_HOSTS = []
# Application definition
 
INSTALLED_APPS = (
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
)
 
MIDDLEWARE_CLASSES = (
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
)
 
ROOT_URLCONF = 'demo.urls'
 
WSGI_APPLICATION = 'demo.wsgi.application'
# Database
 
DATABASES = {
'default': {
'ENGINE''django.db.backends.sqlite3',
'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
}
}
 
# Internationalization
 
LANGUAGE_CODE = 'en-us'
 
TIME_ZONE = 'UTC'
 
USE_I18N = True
 
USE_L10N = True
 
USE_TZ = True
# Static files (CSS, JavaScript, Images)
 
STATIC_URL = '/static/'

Bueno he aprendido que este archivo puede “partirse” de acuerdo a como estemos trabajando.

Lo más común es crear un modulo de Settings en Python.

settings_module

 

Aquí creamos una carpeta llamada settings con el archivo __init__.py que eso lo convierte en un módulo. En su interior contiene 2 archivos uno llamado base.py (que es el archivossettings.py y solo lo he renombrado) y me he creado otro llamado local.py que ahora lo tenemos vacío.

Bueno habiendo hecho eso vamos a empezar a poner nuestros archivos en orden:

base.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
"""
Django settings for demo project.
 
For more information on this file, see
 
For the full list of settings and their values, see
"""
 
# Build paths inside the project like this: os.path.join(BASE_DIR, ...)
import os
BASE_DIR = os.path.dirname(os.path.dirname(__file__))
 
ALLOWED_HOSTS = []
 
# Application definition
 
INSTALLED_APPS = (
 'django.contrib.admin',
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.messages',
 'django.contrib.staticfiles',
)
 
MIDDLEWARE_CLASSES = (
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.common.CommonMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.contrib.auth.middleware.SessionAuthenticationMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware',
 'django.middleware.clickjacking.XFrameOptionsMiddleware',
)
 
ROOT_URLCONF = 'demo.urls'
 
WSGI_APPLICATION = 'demo.wsgi.application'
 
USE_I18N = True
 
USE_L10N = True
 
USE_TZ = True

Este es el contenido de mi archivo base.py, si nos fijamos he quitado algunas cosas y las he puesto en mi archivo local.py.

local.py

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
from .base import *
# Quick-start development settings - unsuitable for production
# SECURITY WARNING: keep the secret key used in production secret!
SECRET_KEY = '!3p5@#!j^fz$6l##cwd6l43&xu#dfb5zu5=#mxd4&s7_azl+8^'
 
# SECURITY WARNING: don't run with debug turned on in production!
DEBUG = True
 
TEMPLATE_DEBUG = True
 
# Database
 
DATABASES = {
 'default': {
 'ENGINE''django.db.backends.sqlite3',
 'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
 }
}
 
# Internationalization
 
LANGUAGE_CODE = 'en-us'
 
TIME_ZONE = 'UTC'
 
# Static files (CSS, JavaScript, Images)
 
STATIC_URL = '/static/'

Lo primero que hago es importar todo lo que está en mi archivo base.py con

1
from .base import *

A continuación tenemos:

  • SECRET_KEY
  • La variable DEBUG
  • TEMPLATE_DEBUG
  • DATABASES
  • LANGUAGE_CODE
  • TIME_ZONE
  • STATIC_URL

Y … ¿cuál es la ventaja o porque hacer esto? Bueno el SECRET_KEY debe ser privado (esto lo tocaremos en futuros artículos), las bases de datos podemos manejar sqlite3 ya que aún estamos desarrollado, todo el contenido de local.py es el que a mí como programador me sirve: DATABASES, MEDIA_ROOT (almancenando las imágenes en nuestro equipo local), la variable DEBUG, y así va cambiando de acuerdo a cada programador: TIME_ZONE, LENGUAGE_CODE, entre otros.

De esta forma cada desarrollador tendrá su propio local.py agregando la app en la que trabaja o herramientas de desarrollo que utiliza, como por ejemplo django debug Toolbar:

1
2
3
4
5
6
7
INSTALLED_APPS += (
 
'mi_app',
 
'debug_toolbar',
 
)

Así mismo, para el momento de pruebas y producción, podemos crearnos tantos archivos settings como sean requeridos: test.py y prod.py; normalmente son los siguientes:

settings

 

En el prod.py, por ejemplo, ya no almacenemos las imágenes en nuestro equipo local sino que podríamos usar configuraciones para que apunte a servidores como Amazon S3.

¿Como corremos esto? bueno … de la siguiente manera, estando ubicados en donde está nuestro manage.py:

Captura de pantalla 2014-09-28 a la(s) 22.07.51

Corremos el comando runserver con algunos parámetros

Captura de pantalla 2014-09-28 a la(s) 22.12.57

que son:  nombre del proyecto, nombre de la carpeta settings y el archivo que queremos correr, en este caso es el local.py. 

Espero que les haya servido este pequeño tutorial y nos leemos en el próximo post.

No olvides seguirnos en nuestras redes sociales:

Twitter | Facebook | Google+

 



Alex Dzul

FullStack Python / Django Developer. #jslove