Django => impostazioni

Impostazione del fuso orario

Puoi impostare il fuso orario che verrà utilizzato da Django nel file settings.py . Esempi:

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

Ecco l'elenco dei fusi orari validi

Quando si esegue in un ambiente Windows , questo deve essere impostato allo stesso fuso orario del sistema .

Se non vuoi che Django utilizzi dati datati con timezone:

USE_TZ = False

Le best practice di Django richiedono l'uso di UTC per l'archiviazione delle informazioni nel database:

Anche se il tuo sito web è disponibile in un unico fuso orario, è comunque buona norma memorizzare i dati in UTC nel tuo database. Il motivo principale è Daylight Saving Time (DST). Molti paesi hanno un sistema di DST, in cui gli orologi vengono spostati in avanti in primavera e indietro in autunno. Se lavori in ora locale, è probabile che tu incontri errori due volte l'anno, quando le transizioni avvengono.

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

Accesso alle impostazioni

Una volta che hai tutte le impostazioni, vorrai usarle nel tuo codice. Per fare ciò, aggiungi la seguente importazione al tuo file:

from django.conf import settings

È quindi possibile accedere alle proprie impostazioni come attributi del modulo delle settings , ad esempio:

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

Utilizzo di BASE_DIR per garantire la portabilità delle app

È una cattiva idea di percorsi di codice complessi nella tua applicazione. Uno dovrebbe sempre usare url relativi in modo che il codice possa funzionare senza problemi su macchine diverse. Il modo migliore per configurarlo è definire una variabile come questa

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

Quindi utilizzare questa variabile BASE_DIR per definire tutte le altre impostazioni.

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

]

E così via. Ciò garantisce che puoi trasferire il tuo codice su macchine diverse senza preoccupazioni.

Tuttavia, os.path è un po ' os.path . Ad esempio se il tuo modulo delle impostazioni è project.settings.dev , dovrai scrivere:

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

Un'alternativa è usare il modulo unipath (che puoi installare 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'),
]

Utilizzo delle variabili di ambiente per gestire le impostazioni tra i server

L'utilizzo delle variabili d'ambiente è un modo ampiamente utilizzato per impostare la configurazione di un'app in base all'ambiente, come indicato nell'app Twelve-Factor .

Poiché è probabile che le configurazioni cambino tra gli ambienti di distribuzione, questo è un modo molto interessante per modificare la configurazione senza dover scavare nel codice sorgente dell'app, oltre a tenere segreti al di fuori dei file dell'applicazione e del repository del codice sorgente.

In Django, le impostazioni principali si trovano come settings.py nella cartella del tuo progetto. Poiché si tratta di un semplice file Python, è possibile utilizzare il modulo os di Python dalla libreria standard per accedere all'ambiente (e persino avere i valori predefiniti appropriati).

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 puoi cambiare la tua tecnologia di database, in modo che tu possa usare sqlite3 sul tuo computer di sviluppo (e questo dovrebbe essere un predefinito corretto per il commit su un sistema di controllo del codice sorgente). Anche se questo è possibile, non è consigliabile:

I servizi di supporto, come il database dell'applicazione, il sistema di accodamento o la cache, sono un'area in cui la parità di sviluppo / sviluppo è importante. ( L'app Twelve-Factor - Dev / prod parity )

Per utilizzare un parametro DATABASE_URL per la connessione al database, si prega di dare un'occhiata all'esempio correlato .

Utilizzando più impostazioni

Il layout di progetto predefinito di Django crea un singolo settings.py . Questo è spesso utile per dividerlo in questo modo:

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

Ciò consente di lavorare con impostazioni diverse a seconda che si tratti di sviluppo, produzione, test o altro.

Quando si passa dal layout predefinito a questo layout, il settings.py originale diventa settings/base.py Quando ogni altro sottomodulo eseguirà una "sottoclasse" di settings/base.py iniziando from .base import * . Ad esempio, ecco come possono essere le 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']

# 1 alternativo

Perché i comandi di django-admin funzionino correttamente, devi impostare la variabile di ambiente DJANGO_SETTINGS_MODULE (che di default è myproject.settings ). In fase di sviluppo, lo imposterai su myproject.settings.dev . In produzione, lo imposterai su myproject.settings.prod . Se si utilizza un virtualenv, è meglio impostarlo nello script postactivate :

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

Se si desidera utilizzare un modulo delle impostazioni che non viene indirizzato da DJANGO_SETTINGS_MODULE per una volta, è possibile utilizzare l'opzione --settings di django-admin :

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

N. 2 alternativo

Se si desidera lasciare DJANGO_SETTINGS_MODULE alla sua configurazione predefinita ( myproject.settings ), è sufficiente indicare al modulo delle settings configurazione da caricare inserendo l'importazione nel file __init__.py .

Nell'esempio sopra, lo stesso risultato potrebbe essere ottenuto avendo un __init__.py impostato su:

from .dev import *

Utilizzo di più file di requisiti

Ogni file di requisiti deve corrispondere al nome di un file di impostazioni. Leggi Utilizzo di più impostazioni per ulteriori informazioni.

Struttura

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

Nel file base.txt , posiziona le dipendenze utilizzate in tutti gli ambienti.

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

E in tutti gli altri file, includere le dipendenze di base con -r base.txt e aggiungere specifiche dipendenze necessarie per l'ambiente corrente.

# 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

Infine, per installare le dipendenze. Esempio, su dev env: pip install -r config/requirements/dev.txt

Nascondere i dati segreti utilizzando un file JSON

Quando si utilizza un VCS come Git o SVN, ci sono alcuni dati segreti che non devono mai essere sottoposti a versionamento (se il repository è pubblico o privato).

Tra questi dati, si trova l'impostazione SECRET_KEY e la password del database.

Una pratica comune per nascondere queste impostazioni dal controllo di versione è creare un file secrets.json alla radice del progetto ( grazie a " Two Scoops of Django " per l'idea ):

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

E aggiungilo alla tua lista di cose da ignorare ( .gitignore per git):

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

Quindi aggiungere la seguente funzione al modulo delle 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))

Quindi riempi le impostazioni in questo modo:

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

Utilizzo di DATABASE_URL dall'ambiente

Nei siti PaaS come Heroku, è normale ricevere le informazioni del database come una singola variabile di ambiente URL, invece di diversi parametri (host, porta, utente, password ...).

Esiste un modulo, dj_database_url che estrae automaticamente la variabile d'ambiente DATABASE_URL in un dizionario Python appropriato per l'iniezione delle impostazioni del database in Django.

Uso:

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

Autorizzato sotto CC BY-SA 3.0

Non affiliato con Stack Overflow

Django
impostazioni

Ricerca…