Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add settings for different envs #40

Open
sobolevn opened this issue Jun 1, 2017 · 0 comments
Open

Add settings for different envs #40

sobolevn opened this issue Jun 1, 2017 · 0 comments

Comments

@sobolevn
Copy link

sobolevn commented Jun 1, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant