Django => настройки

Установка часового пояса

Вы можете установить часовой пояс, который будет использоваться Django в файле settings.py . Примеры:

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

Вот список действительных часовых поясов

При работе в среде Windows это должно быть установлено так же, как и в системном часовом поясе .

Если вы не хотите, чтобы Django использовал временные данные, относящиеся к часовому поясу:

USE_TZ = False

Лучшие практики Django требуют использовать UTC для хранения информации в базе данных:

Даже если ваш сайт доступен только в одном часовом поясе, по-прежнему рекомендуется хранить данные в формате UTC в вашей базе данных. Основная причина - переход на летнее время (DST). Во многих странах существует система DST, где осенью осенью весной и осенью часы продвигаются вперед. Если вы работаете в местное время, вы, вероятно, столкнетесь с ошибками два раза в год, когда происходят переходы.

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

Доступ к настройкам

После того, как вы получите все свои настройки, вы захотите использовать их в своем коде. Для этого добавьте следующий импорт в свой файл:

from django.conf import settings

Затем вы можете получить доступ к своим настройкам в качестве атрибутов модуля settings , например:

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

Использование BASE_DIR для обеспечения мобильности приложений

Это плохая идея для жестких путей кода в вашем приложении. Всегда нужно использовать относительные URL-адреса, чтобы ваш код мог легко работать на разных машинах. Лучший способ установить это - определить такую переменную, как это

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

Затем используйте эту переменную BASE_DIR чтобы определить все остальные настройки.

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

]

И так далее. Это гарантирует, что вы можете переносить свой код на разные машины без каких-либо проблем.

Однако os.path является немного подробным. Например, если ваш модуль настроек - project.settings.dev , вам нужно будет написать:

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

Альтернативой является использование unipath модуля (который вы можете установить с помощью 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'),
]

Использование переменных среды для управления настройками на серверах

Использование переменных среды является широко используемым способом настройки конфигурации приложения в зависимости от его среды, как указано в приложении Twelve-Factor .

Поскольку конфигурации, вероятно, будут меняться между средами развертывания, это очень интересный способ изменить конфигурацию без необходимости копать исходный код приложения, а также хранить секреты вне файлов приложений и репозитория исходного кода.

В Django основные настройки находятся в settings.py в папке вашего проекта. Поскольку это простой файл Python, вы можете использовать os модуль Python из стандартной библиотеки для доступа к среде (и даже иметь соответствующие значения по умолчанию).

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

С помощью Django вы можете изменить свою технологию баз данных, чтобы вы могли использовать sqlite3 на своей машине разработки (и это должно быть нормальным по умолчанию для передачи в систему управления версиями). Хотя это возможно, это нецелесообразно:

Резервные службы, такие как база данных приложения, система очередей или кеш, являются одной областью, где важна четность dev / prod. ( Двенадцатифакторное приложение - паритет Dev / prod )

Для использования параметра DATABASE_URL для подключения к базе данных см. Соответствующий пример .

Использование нескольких настроек

По умолчанию проект Django по умолчанию создает один settings.py . Часто бывает полезно разбить его следующим образом:

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

Это позволяет работать с разными настройками в зависимости от того, работаете ли вы в разработке, производстве, тестах или что-то еще.

При переходе от макета по умолчанию к этому макету исходные settings.py становятся settings/base.py Когда каждый другой подмодуль будет «подклассировать» settings/base.py , начиная с from .base import * . Например, вот какие 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

Для правильной работы команд django-admin вам нужно будет установить переменную среды DJANGO_SETTINGS_MODULE (которая по умолчанию соответствует myproject.settings ). В процессе разработки вы установите его на myproject.settings.dev . В процессе производства вы установите его на myproject.settings.prod . Если вы используете virtualenv, лучше всего установить его в сценарий postactivate :

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

Если вы хотите использовать модуль настроек, который не указывается DJANGO_SETTINGS_MODULE за один раз, вы можете использовать опцию --settings django-admin :

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

Альтернатива №2

Если вы хотите оставить DJANGO_SETTINGS_MODULE в своей конфигурации по умолчанию ( myproject.settings ), вы можете просто сказать модулю settings какую конфигурацию загружать, поместив импорт в ваш файл __init__.py .

В приведенном выше примере тот же результат может быть достигнут с помощью набора __init__.py для:

from .dev import *

Использование нескольких файлов требований

Каждый файл требований должен соответствовать имени файла настроек. Прочтите несколько настроек для получения дополнительной информации.

Состав

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

В файле base.txt установите зависимости, используемые во всех средах.

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

И во всех других файлах -r base.txt базовые зависимости с -r base.txt и добавьте определенные зависимости, необходимые для текущей среды.

# 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

Наконец, для установки зависимостей. Пример, на dev env: pip install -r config/requirements/dev.txt

Скрытие секретных данных с использованием файла JSON

При использовании VCS, такого как Git или SVN, есть некоторые секретные данные, которые никогда не должны быть версиями (будь то публичный или закрытый репозиторий).

Среди этих данных вы найдете параметр SECRET_KEY и пароль базы данных.

Общей практикой скрыть эти настройки от контроля версий является создание файла secrets.json в корне вашего проекта ( спасибо « Two Scoops of Django » за идею ):

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

И добавьте его в свой список игнорирования ( .gitignore для git):

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

Затем добавьте в свой модуль 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))

Затем заполните настройки таким образом:

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

Использование DATABASE_URL из среды

На сайтах PaaS, таких как Heroku, обычно необходимо получать информацию о базе данных как единственную переменную среды URL, а не несколько параметров (хост, порт, пользователь, пароль ...).

Существует модуль dj_database_url который автоматически извлекает переменную среды DATABASE_URL в словарь Python, подходящий для ввода параметров базы данных в Django.

Использование:

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

Лицензировано согласно CC BY-SA 3.0

Не связан с Stack Overflow

Django
настройки

Поиск…