django-hackathon-starter icon indicating copy to clipboard operation
django-hackathon-starter copied to clipboard

Add settings for different envs

Open sobolevn opened this issue 7 years ago • 0 comments

This project is an awesome project starter. Thanks!

Problem

But one thing caught my eye: there's only one configuration file for all possible envs: development, stage, testing, production and local.

Maybe it would be a good idea to add some kind of library to handle that? Some popular examples: django-configurations and django-split-settings.

Also, adding a lot of social providers inside the same settings file may grow it long and nasty.

Solution

Here's a brief example, how to use django-split-settings. We will need new settings package structure:

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

And here's settings/__init__.py:

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

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

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

ENV = environ.get('DJANGO_ENV') or 'production'  # since it's a production-ready template

base_settings = [
    'components/common.py',  # standard django settings
    'components/database.py',  # database setup
    
    # Select the right env:
    'environments/%s.py' % ENV,
    # Optionally override some settings:
    optional('environments/local.py'),
]

# Include settings:
include(*base_settings)

So after that it would be crystal-clear for users where to put extra configurations like: django-debug-toolbar and other which are used for development or testing only.

Conclusion

Pros:

  • Clear settings structure
  • No refactoring and no effect on the end user
  • Multiple possible environments with reasonable default

Cons:

  • Extra dependency

Maybe I am missing any cons, please correct me if I am wrong.

Further readings

Here's a detailed article I wrote on this topic: https://medium.com/wemake-services/managing-djangos-settings-e2b7f496120d


So, what do you think? I will send a PR if that's fine.

sobolevn avatar Jun 01 '17 08:06 sobolevn