Django настройки?

Question

[Antigo_ptz]

Ребят, вопрос таков.
В проекте Django есть файл с настройками settings.py. Я хочу сделать настройки более читабельными, такого вида:
DATABASE_NAME = 'db'
DATABASE_HOST = '192.168.1.22' и т.п
и вынести в файл settings.ini за пределы проекта, а в файле settings.py читать их из settings.ini посредством стандартной питоновской библиотеки configparser https://docs.python.org/3/library/configparser.html
В итоге в файле settings.py будет что-то подобное:

import configparser
config = configparser.ConfigParser()
config.read('/opt/settings/settings.ini')
system = config['SYSTEM']

DATABASES = {
    'default': {
        'NAME': config.get('SYSTEM', 'DATABASE_NAME'),
        'ENGINE': 'django.db.backends.postgresql',
        'USER': config.get('SYSTEM', 'DATABASE_USER'),
        'PASSWORD': config.get('SYSTEM', 'DATABASE_PASSWORD'),
        'HOST': config.get('SYSTEM', 'DATABASE_HOST'),
        'PORT': config.get('SYSTEM', 'DATABASE_PORT'),
        },
    }
 ...
 ...

файл /opt/settings/settings.ini

[SYSTEM]

DATABASE_NAME = 'db'
DATABASE_USER = 'admin'
DATABASE_PASSWORD = '12345678'
DATABASE_HOST = '192.168.1.22'
DATABASE_PORT = '5432'

Вопрос в том, как-то это повлияет на работу системы? Сам Django как работает с настройками, один раз прочитал и использует или стучится постоянно в settings.py по необходимости?

Comments

[Павел Аксенов]

Один раз прочитает.

Answer 1

[Roman K]

Все константы держатся в оперативной памяти. Не понимаю, зачем усложнять себе жизнь и создавать ещё один слой с настройками. Да, это паршиво, что джанга хранит конфиг кодом, но это джанга. И либо создавать универсальный reusable app, либо храни как все. Пока это смотрится, как огромный костыль.

Comments

[Antigo_ptz]

с удовольствием бы оставил как есть, но руководство требует "читабельные настройки", чтобы заказчики сами могли их легко изменять. Формат json им не по нраву. Во-вторых, при обновлении системы на продакшене, все настройки перезатрутся в проекте, если же их вынести в отдельную директорию и в settings.py ссылаться на них, то каждый заказчик сможет раз настроить их и они не будут перезатираться при обновах

[Roman K]

Antigo_ptz: Эти настройки опасно менять "заказчикам". Особенно таким, которые не в силах осилить конфиг джанги. Никто не перезатрётся, если сделать несколько файлов как settings.py. Например:
base.py — для общих настроек
stage.py — для стейджа. Наследует всё из base (from .base import *)
prod.py
dev.py
И писать export DJANGO_SETTINGS_MODULE=yourproject.prod

[Antigo_ptz]

Roman Kitaev: дело в том, что я уже вынес все настройки, которые используются всем заказчиками в base.py и они поставляются вместе с обновлениями проекта, тот файл, что я описал - это как-раз production.py, которй ссылается на base.py, в нем не много настроек, только подключение к бд, redis да еще несколько других.

[Antigo_ptz]

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

Answer 2

[sim3x]

Тут два измерения проблем
Первый уже описал Роман - есть несколько типов настроек - прод, тест, дев
Они могут иметь различия
Все настроки хранятся в репозитории
Те текст открыт
Ето плохо и не безопасно

Одно из решений - переменные окружения
stackoverflow.com/a/20909045

Берем файл .env

$ cat ~/.env
DATABASE_NAME=db
DATABASE_USER=admin
DATABASE_PASSWORD=12345678
DATABASE_HOST=192.168.1.22
DATABASE_PORT=5432
SECRET_KEY=SECRET_KEY

добавляем в .bashrc

export $(cat $HOME/.env | xargs)

В настройках продавшена джанго делаем

from os import environ
# ...
SECRET_KEY = environ('SECRET_KEY')
# ...

Изменения в файл не будут подхвачены автоматом - нужно будет перезагружать uWSGI