Gerenciando configurações do Django

Antes de começar, você precisará instalar django-split-settingscom pip install django-split-settings. Este auxiliar fornece uma interface amigável para armazenar suas configurações em arquivos diferentes. Vejamos o exemplo. Imagine que você tem um projeto existente com django, postgres, redis, rq, e e-mails.

É assim que seus arquivos ficariam após a adoção django-split-settingse alguma reestruturação manual:

your_project/settings/
├── __init__.py
├── components
│   ├── __init__.py
│   ├── database.py
│   ├── common.py
│   ├── emails.py
│   ├── rq.py
└── environments
    ├── __init__.py
    ├── development.py
    ├── local.py.template
    ├── production.py
    └── testing.py

Essa é uma separação clara das configurações com base em dois fatores: qual componente eles estão configurando e em qual ambiente estamos trabalhando agora. E a flexibilidade da biblioteca permite que você tenha qualquer estrutura que desejar, não apenas a descrita aqui.
Em nosso settings/__init__.py, podemos definir qualquer lógica que quisermos. Basicamente, definiríamos apenas que tipo de componentes gostaríamos de usar e selecionaríamos o ambiente. Aqui está um exemplo que usamos na produção para todos os nossos projetos:

"""
This is a django-split-settings main file.
For more information read this:
https://github.com/sobolevn/django-split-settings

Default environment is `developement`.
To change settings file:
`DJANGO_ENV=production python manage.py runserver`
"""

from split_settings.tools import optional, include
from os import environ

ENV = environ.get('DJANGO_ENV') or 'development'

base_settings = [
    'components/common.py',  # standard django settings
    'components/database.py',  # postgres
    'components/rq.py',  # redis and redis-queue
    'components/emails.py',  # smtp

    # You can even use glob:
    # 'components/*.py'

    # Select the right env:
    'environments/%s.py' % ENV,
    # Optionally override some settings:
    optional('environments/local.py'),
]

# Include settings:
include(*base_settings)

E é isso. Nosso aplicativo funcionaria normalmente. Alcançamos vários objetivos com tão poucas linhas de código:

1. Agora temos configurações separadas com base no que eles configuram. Obtendo legibilidade e manutenção
2. Agora temos configurações separadas com base no ambiente
3. Agora temos configurações locais opcionais com hacks sujos
4. Não tivemos que fazer nenhuma refatoração, exceto apenas alguma reestruturação básica

Leia o artigo completo: https://medium.com/wemake-services/managing-djangos-settings-e2b7f496120d