Django => instellingen

Tijdzone instellen

U kunt de tijdzone instellen die door Django wordt gebruikt in het bestand settings.py . Voorbeelden:

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

Hier is de lijst met geldige tijdzones

Wanneer u in een Windows- omgeving werkt, moet dit op dezelfde tijdzone worden ingesteld als uw systeem .

Als u niet wilt dat Django tijdzone-bewuste datetijden gebruikt:

USE_TZ = False

Django best practices vragen om UTC voor het opslaan van informatie in de database:

Zelfs als uw website in slechts één tijdzone beschikbaar is, is het nog steeds een goede gewoonte om gegevens in UTC in uw database op te slaan. De belangrijkste reden is Zomertijd (DST). Veel landen hebben een DST-systeem, waarbij klokken vooruit worden bewogen in het voorjaar en achteruit in het najaar. Als u in lokale tijd werkt, zult u waarschijnlijk twee keer per jaar fouten tegenkomen, wanneer de overgangen plaatsvinden.

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

Toegang tot instellingen

Als je eenmaal al je instellingen hebt, wil je ze in je code gebruiken. Voeg hiervoor de volgende import aan uw bestand toe:

from django.conf import settings

U hebt dan toegang tot uw instellingen als attributen van de settings , bijvoorbeeld:

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

BASE_DIR gebruiken om portabiliteit van apps te garanderen

Het is een slecht idee om harde codepaden in uw toepassing te gebruiken. Men moet altijd relatieve urls gebruiken, zodat uw code naadloos op verschillende machines kan werken. De beste manier om dit in te stellen is om een variabele als deze te definiëren

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

Gebruik vervolgens deze variabele BASE_DIR om al uw andere instellingen te definiëren.

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

]

Enzovoorts. Dit zorgt ervoor dat u uw code zonder zorgen op verschillende machines kunt overzetten.

os.path is echter een beetje uitgebreid. Als uw instellingsmodule bijvoorbeeld project.settings.dev , moet u het volgende schrijven:

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

Een alternatief is om de unipath module te gebruiken (die u kunt installeren met 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'),
]

Omgevingsvariabelen gebruiken om instellingen op verschillende servers te beheren

Het gebruik van omgevingsvariabelen is een veelgebruikte manier om de configuratie van een app in te stellen afhankelijk van de omgeving, zoals vermeld in de Twaalf-Factor-app .

Aangezien configuraties waarschijnlijk zullen veranderen tussen de implementatie-omgevingen, is dit een zeer interessante manier om de configuratie te wijzigen zonder de broncode van de app te hoeven graven, en geheimen te bewaren buiten de applicatiebestanden en de broncode-repository.

In Django bevinden de hoofdinstellingen zich als settings.py in de map van uw project. Omdat het een eenvoudig Python-bestand is, kunt u de os module van Python uit de standaardbibliotheek gebruiken om toegang te krijgen tot de omgeving (en zelfs de juiste standaardwaarden hebben).

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

Met Django kunt u uw databasetechnologie wijzigen, zodat u sqlite3 op uw ontwikkelmachine kunt gebruiken (en dat zou een goede standaard moeten zijn voor het vastleggen van een broncontrolesysteem). Hoewel dit mogelijk is, is het niet raadzaam:

Back-upservices, zoals de database van de app, het wachtrijsysteem of de cache, is een gebied waar dev / prod-pariteit belangrijk is. ( De Twaalf-Factor App - Dev / prod parity )

Bekijk het gerelateerde voorbeeld voor het gebruik van een DATABASE_URL-parameter voor databaseverbinding.

Meerdere instellingen gebruiken

Django standaard projectlay-out maakt een enkele settings.py . Dit is vaak handig om het als volgt te splitsen:

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

Hierdoor kunt u met verschillende instellingen werken, afhankelijk van of u in ontwikkeling, productie, tests of wat dan ook bent.

Wanneer u van de standaardlay-out naar deze lay-out gaat, wordt de oorspronkelijke settings.py settings/base.py Wanneer elke andere submodule settings/base.py "subklasse" door te beginnen met from .base import * . Dit is bijvoorbeeld hoe settings/dev.py kunnen zien:

# -*- 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']

Alternatief # 1

Om django-admin opdrachten goed te laten werken, moet u de omgevingsvariabele DJANGO_SETTINGS_MODULE instellen (standaard ingesteld op myproject.settings ). In ontwikkeling stelt u deze in op myproject.settings.dev . In productie stelt u deze in op myproject.settings.prod . Als u een virtualenv gebruikt, kunt u deze het beste in uw postactivate :

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

Als je een instellingenmodule wilt gebruiken die niet één keer door DJANGO_SETTINGS_MODULE wordt aangewezen, kun je de optie --settings van django-admin :

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

Alternatief # 2

Als u DJANGO_SETTINGS_MODULE in de standaardconfiguratie ( myproject.settings ) wilt laten, kunt u de settings eenvoudig vertellen welke configuratie moet worden geladen door de import in uw __init__.py . __init__.py bestand te plaatsen.

In het bovenstaande voorbeeld kan hetzelfde resultaat worden bereikt door een __init__.py ingesteld op:

from .dev import *

Meerdere vereiste bestanden gebruiken

Elke vereiste bestanden moeten overeenkomen met de naam van een instellingenbestand. Lees Meerdere instellingen gebruiken voor meer informatie.

Structuur

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

base.txt in het base.txt bestand afhankelijkheden die in alle omgevingen worden gebruikt.

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

En -r base.txt in alle andere bestanden -r base.txt met -r base.txt en voeg specifieke afhankelijkheden toe die nodig zijn voor de huidige omgeving.

# 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

Ten slotte, om afhankelijkheden te installeren. Voorbeeld op dev env: pip install -r config/requirements/dev.txt

Verborgen gegevens verbergen met een JSON-bestand

Bij het gebruik van een VCS zoals Git of SVN, zijn er enkele geheime gegevens die nooit moeten worden bijgewerkt (of de repository openbaar of privé is).

Onder die gegevens vindt u de instelling SECRET_KEY en het wachtwoord van de database.

Een gebruikelijke praktijk om deze instellingen te verbergen voor versiebeheer is om een bestand secrets.json in de hoofdmap van uw project ( bedankt " Two Scoops of Django " voor het idee ):

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

En voeg het toe aan je negeerlijst ( .gitignore voor git):

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

Voeg vervolgens de volgende functie toe aan uw 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))

Vul vervolgens de instellingen op deze manier in:

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

Een DATABASE_URL uit de omgeving gebruiken

Op PaaS-sites zoals Heroku is het gebruikelijk om de database-informatie te ontvangen als een enkele omgevingsvariabele in plaats van meerdere parameters (host, poort, gebruiker, wachtwoord ...).

Er is een module, dj_database_url die de omgevingsvariabele DATABASE_URL automatisch dj_database_url in een Python-woordenboek dat geschikt is voor het injecteren van de database-instellingen in Django.

Gebruik:

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

Licentie onder CC BY-SA 3.0

Niet aangesloten bij Stack Overflow

Django
instellingen

Zoeken…