Django => Paramètres

Définition du fuseau horaire

Vous pouvez définir le fuseau horaire qui sera utilisé par Django dans le fichier settings.py . Exemples:

TIME_ZONE = 'UTC'  # use this, whenever possible
TIME_ZONE = 'Europe/Berlin'
TIME_ZONE = 'Etc/GMT+1'

Voici la liste des fuseaux horaires valables

Lors de l'exécution dans un environnement Windows , cette zone doit être identique à celle du fuseau horaire de votre système .

Si vous ne voulez pas que Django utilise des dates-heures sensibles au fuseau horaire:

USE_TZ = False

Les meilleures pratiques de Django demandent d’utiliser UTC pour stocker des informations dans la base de données:

Même si votre site Web est disponible dans un seul fuseau horaire, il est toujours recommandé de stocker les données en UTC dans votre base de données. La raison principale est l'heure d'été (DST). De nombreux pays ont un système de DST, où les horloges sont avancées au printemps et en arrière en automne. Si vous travaillez à l'heure locale, vous risquez de rencontrer des erreurs deux fois par an, lorsque les transitions se produisent.

https://docs.djangoproject.com/en/stable/topics/i18n/timezones/

Accéder aux paramètres

Une fois que vous avez tous vos paramètres, vous voudrez les utiliser dans votre code. Pour cela, ajoutez l'importation suivante à votre fichier:

from django.conf import settings

Vous pouvez ensuite accéder à vos paramètres en tant qu'attributs du module de settings , par exemple:

if not settings.DEBUG:
    email_user(user, message)

Utiliser BASE_DIR pour assurer la portabilité des applications

Il est déconseillé de coder des chemins dans votre application. Il faut toujours utiliser des URL relatives pour que votre code puisse fonctionner de manière transparente sur différentes machines. La meilleure façon de configurer cela est de définir une variable comme celle-ci.

import os
BASE_DIR = os.path.dirname(os.path.dirname(__file__))

Ensuite, utilisez cette variable BASE_DIR pour définir tous vos autres paramètres.

TEMPLATE_PATH = os.path.join(BASE_DIR, "templates")
STATICFILES_DIRS = [
    os.path.join(BASE_DIR, "static"),

]

Etc. Cela garantit que vous pouvez porter votre code sur différentes machines sans aucun souci.

Cependant, os.path est un peu verbeux. Par exemple, si votre module de paramètres est project.settings.dev , vous devrez écrire:

BASE_DIR = os.path.dirname(os.path.dirname(os.path.dirname(__file__)))

Une alternative consiste à utiliser le module unipath (que vous pouvez installer avec 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'),
]

Utilisation de variables d'environnement pour gérer les paramètres sur les serveurs

L'utilisation de variables d'environnement est un moyen largement utilisé pour définir la configuration d'une application en fonction de son environnement, comme indiqué dans l'application Twelve-Factor .

Comme les configurations sont susceptibles de changer entre les environnements de déploiement, c'est une manière très intéressante de modifier la configuration sans avoir à creuser le code source de l'application, ainsi qu'à garder des secrets en dehors des fichiers d'application et du référentiel de code source.

Dans Django, les paramètres principaux se trouvent sous le nom settings.py dans le dossier de votre projet. Comme il s'agit d'un simple fichier Python, vous pouvez utiliser le module os de Python depuis la bibliothèque standard pour accéder à l'environnement (et même disposer des paramètres par défaut appropriés).

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,
    }
}

Avec Django, vous pouvez modifier la technologie de votre base de données, de sorte que vous puissiez utiliser sqlite3 sur votre machine de développement (ce qui devrait être une option saine pour s’engager dans un système de contrôle de source). Bien que cela soit possible, il est déconseillé:

Les services de support, tels que la base de données de l'application, le système de mise en file d'attente ou le cache, constituent un domaine où la parité dev / prod est importante. ( The Twelve-Factor App - Parité Dev / prod )

Pour utiliser un paramètre DATABASE_URL pour la connexion à la base de données, consultez l' exemple associé .

Utiliser plusieurs paramètres

La structure de projet par défaut de Django crée un seul settings.py . Ceci est souvent utile pour le diviser comme ceci:

myprojectroot/
    myproject/
        __init__.py
        settings/
            __init__.py
            base.py
            dev.py
            prod.py
            tests.py

Cela vous permet de travailler avec différents paramètres selon que vous soyez en développement, en production, en tests ou autre.

Lorsque vous passez de la présentation par défaut à cette présentation, le settings/base.py settings.py origine devient settings/base.py Lorsque tous les autres sous-modules "sous settings/base.py " settings/base.py en commençant par à partir from .base import * . Par exemple, voici à quoi peuvent ressembler 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']

Alternative n ° 1

Pour django-admin commandes django-admin fonctionnent correctement, vous devrez définir la variable d'environnement DJANGO_SETTINGS_MODULE (qui par défaut est myproject.settings ). En développement, vous allez le définir sur myproject.settings.dev . En production, vous le définissez sur myproject.settings.prod . Si vous utilisez un virtualenv, le mieux est de le définir dans votre script postactivate :

#!/bin/sh
export PYTHONPATH="/home/me/django_projects/myproject:$VIRTUAL_ENV/lib/python3.4"
export DJANGO_SETTINGS_MODULE="myproject.settings.dev"

Si vous souhaitez utiliser un module de paramètres qui ne sont pas fait par DJANGO_SETTINGS_MODULE pour une fois, vous pouvez utiliser la --settings option django-admin :

django-admin test --settings=myproject.settings.tests

Alternative n ° 2

Si vous souhaitez laisser DJANGO_SETTINGS_MODULE à sa configuration par défaut ( myproject.settings ), vous pouvez simplement indiquer au module de settings quelle configuration charger en plaçant l’importation dans votre fichier __init__.py .

Dans l'exemple ci-dessus, le même résultat peut être obtenu en __init__.py un __init__.py sur:

from .dev import *

Utiliser plusieurs fichiers de besoins

Chaque fichier de configuration doit correspondre au nom d'un fichier de paramètres. Lire Utilisation de plusieurs paramètres pour plus d'informations.

Structure

djangoproject
├── config
│   ├── __init__.py
│   ├── requirements
│   │   ├── base.txt
│   │   ├── dev.txt
│   │   ├── test.txt
│   │   └── prod.txt
│   └── settings
└── manage.py

Dans le fichier base.txt , placez les dépendances utilisées dans tous les environnements.

# base.txt
Django==1.8.0
psycopg2==2.6.1
jinja2==2.8

Et dans tous les autres fichiers, incluez les dépendances de base avec -r base.txt , et ajoutez des dépendances spécifiques nécessaires pour l'environnement actuel.

# 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

Enfin, pour installer des dépendances. Exemple, sur dev env: pip install -r config/requirements/dev.txt

Masquage de données secrètes à l'aide d'un fichier JSON

Lorsque vous utilisez un VCS tel que Git ou SVN, il existe des données secrètes qui ne doivent jamais être versionnées (que le référentiel soit public ou privé).

Parmi ces données, vous trouvez le paramètre SECRET_KEY et le mot de passe de la base de données.

Une pratique courante pour masquer ces paramètres du contrôle de version consiste à créer un fichier secrets.json à la racine de votre projet ( merci " Two Scoops of Django " pour l'idée ):

{
    "SECRET_KEY": "N4HE:AMk:.Ader5354DR453TH8SHTQr",
    "DB_PASSWORD": "v3ry53cr3t"
}

Et ajoutez-le à votre liste des .gitignore ( .gitignore pour git):

*.py[co]
*.sw[po]
*~
/secrets.json

Ajoutez ensuite la fonction suivante à votre module 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))

Remplissez ensuite les paramètres de la manière suivante:

SECRET_KEY = get_secret('SECRET_KEY')
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgres',
        'NAME': 'db_name',
        'USER': 'username',
        'PASSWORD': get_secret('DB_PASSWORD'),
    },
}

Utiliser un DATABASE_URL de l'environnement

Dans les sites PaaS tels que Heroku, il est courant de recevoir les informations de la base de données sous la forme d'une seule variable d'environnement URL, au lieu de plusieurs paramètres (hôte, port, utilisateur, mot de passe ...).

Il existe un module, dj_database_url qui extrait automatiquement la variable d'environnement DATABASE_URL dans un dictionnaire Python approprié pour injecter les paramètres de base de données dans Django.

Usage:

import dj_database_url

if os.environ.get('DATABASE_URL'):
    DATABASES['default'] =
        dj_database_url.config(default=os.environ['DATABASE_URL'])

Modified text is an extract of the original Stack Overflow Documentation

Sous licence CC BY-SA 3.0

Non affilié à Stack Overflow

Django
Paramètres

Recherche…