Django => inställningar

Ställa in tidszonen

Du kan ställa in tidszonen som ska användas av Django i filen settings.py . Exempel:

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

Här är listan över giltiga tidszoner

När du kör i en Windows- miljö måste detta vara inställt på samma som systemets tidszon .

Om du inte vill att Django ska använda tidszonmedvetna datatider:

USE_TZ = False

Django bästa metoder kräver användning av UTC för att lagra information i databasen:

Även om din webbplats är tillgänglig endast i en tidszon är det fortfarande god praxis att lagra data i UTC i din databas. Det främsta skälet är sommartid (DST). Många länder har ett system av DST, där klockor flyttas framåt på våren och bakåt på hösten. Om du arbetar i lokal tid kommer du troligtvis att träffa fel två gånger om året när övergången händer.

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

Åtkomst till inställningar

När du har fått alla dina inställningar vill du använda dem i din kod. För att göra det, lägg till följande import till din fil:

from django.conf import settings

Du kan sedan komma åt dina inställningar som attribut för settings , till exempel:

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

Använd BASE_DIR för att säkerställa appportabilitet

Det är en dålig idé att hårda kodvägar i din applikation. Man bör alltid använda relativa webbadresser så att din kod kan fungera sömlöst på olika maskiner. Det bästa sättet att konfigurera detta är att definiera en variabel som denna

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

BASE_DIR denna variabel BASE_DIR att definiera alla dina andra inställningar.

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

]

Och så vidare. Detta garanterar att du kan porta din kod över olika maskiner utan några bekymmer.

os.path är dock lite uttryckligt. Om din inställningsmodul till exempel är project.settings.dev , måste du skriva:

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

Ett alternativ är att använda unipath modulen (som du kan installera med 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'),
]

Använda miljövariabler för att hantera inställningar över servrar

Att använda miljövariabler är ett allmänt använt sätt att ställa in en apps konfiguration beroende på den miljö, som anges i The Twelve-Factor App .

Eftersom konfigurationer sannolikt kommer att ändras mellan implementeringsmiljöer, är detta ett mycket intressant sätt att ändra konfigurationen utan att behöva gräva i appens källkod, samt att hålla hemligheter utanför applikationsfilerna och källkodförvaret.

I Django finns huvudinställningarna som settings.py i projektets mapp. Eftersom det är en enkel Python-fil kan du använda Pythons os modul från standardbiblioteket för att komma åt miljön (och till och med ha lämpliga standardvärden).

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

Med Django kan du ändra din databasteknik så att du kan använda sqlite3 på din utvecklingsmaskin (och det borde vara ett sant standard för att kommunicera till ett källkontrollsystem). Även om detta är möjligt rekommenderas det inte:

Säkerhetstjänster, som appens databas, kösystem eller cache, är ett område där dev / prod-paritet är viktigt. ( The Twelve-Factor App - Dev / prod parity )

Om du använder en DATABASE_URL-parameter för databasanslutning, ta en titt på det relaterade exemplet .

Använda flera inställningar

Django standardprojektlayout skapar en enda settings.py . Detta är ofta användbart för att dela upp det så här:

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

Detta gör att du kan arbeta med olika inställningar beroende på om du är i utveckling, produktion, tester eller vad som helst.

När du flyttar från standardlayouten till denna layout, den ursprungliga settings.py blir settings/base.py . När varje annan undermodul kommer att "underklassa" settings/base.py genom att börja med from .base import * . Här är till exempel hur settings/dev.py kan se ut:

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

Alternativ nr 1

För att django-admin kommandon ska fungera ordentligt måste du ställa in DJANGO_SETTINGS_MODULE miljövariabel (som inte är standard för myproject.settings ). Under utveckling kommer du att ställa in det till myproject.settings.dev . I produktionen ställer du in det på myproject.settings.prod . Om du använder en virtualenv är det bäst att ställa in det i ditt postactivate script:

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

Om du vill använda en inställningsmodul som inte pekas av DJANGO_SETTINGS_MODULE på en gång kan du använda - --settings i django-admin :

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

Alternativ # 2

Om du vill lämna DJANGO_SETTINGS_MODULE vid dess standardkonfiguration ( myproject.settings ), kan du helt enkelt berätta settings vilken konfiguration som ska laddas genom att placera importen i din __init__.py fil.

I exemplet ovan kan samma resultat uppnås genom att ha en __init__.py inställd på:

from .dev import *

Använda flera kravfiler

Varje kravfiler ska matcha namnet på en inställningsfil. Läs Använda flera inställningar för mer information.

Strukturera

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

I base.txt fil, placera beroenden som används i alla miljöer.

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

Och i alla andra filer, inkludera -r base.txt med -r base.txt och lägg till specifika beroende som behövs för den aktuella miljön.

# 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

Slutligen, för att installera beroenden. Exempel på dev env: pip install -r config/requirements/dev.txt

Dölja hemliga data med hjälp av en JSON-fil

När du använder en VCS som Git eller SVN finns det några hemliga data som aldrig får versioneras (vare sig förvaret är offentligt eller privat).

Bland dessa data hittar du SECRET_KEY inställningen och databaslösenordet.

En vanlig praxis för att dölja dessa inställningar från versionskontroll är att skapa en secrets.json i roten till ditt projekt ( tack " Två skopor av Django " för idén ):

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

Och lägg till den i din ignorera lista ( .gitignore for git):

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

Lägg sedan till följande funktion i din 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))

Fyll sedan på inställningarna på detta sätt:

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

Använda en DATABASE_URL från miljön

På PaaS-webbplatser som Heroku är det vanligt att ta emot databasinformationen som en enda URL-miljövariabel, istället för flera parametrar (värd, port, användare, lösenord ...).

Det finns en modul, dj_database_url som automatiskt extraherar miljövariabeln DATABASE_URL till en Python-ordbok som är lämplig för att injicera databasinställningarna i Django.

Användande:

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

Licensierat under CC BY-SA 3.0

Inte anslutet till Stack Overflow

Django
inställningar

Sök…