teracyhq-incubator/django-boilerplate

django-boilerplate promotes best practices to organize and start any Django project

django-boilerplate's Issues

better logging configuration and handler

should organize urls module better

urls module is organized so that there is global urls for all projects and project
urls for each specific project.

• global urls are updated by django-boilerplate itself
• project urls are updated by each specific project itself

The hierarchy structure:

• urls.common > project.common -> urls.dev -> project.dev
• urls.common -> project.common -> urls.prod -> project.prod
• urls.common -> project.common -> urls.stag -> project.stag

project.common is used to override urls.common
project.dev is used to override urls.dev
project.prod is used to override urls.prod
project.stag is used to override urls.stag

dev, prod and stag are settings for development, production and staging environment respectively

migrate Site data for dev, stag and prod modes

it's useful for Site.domain to be reflected in different modes.

Add TDD practice into project

tox: http://tox.readthedocs.org/en/latest/

should support send mass html mails

should create mail lib to support sending mass html mails

should support optional celery app

should support optional celery app celeryproject.org

update README after renaming teracy to teracy-django-boilerplate

audit the settings and overall organization to keep up to date with Django 1.8.x

some settings are configured from very old Django versions, we need to audit and make sure to have best practices default settings from Django 1.8.x

should support better environment processing lib

introduce env_vars.py lib as as base for heroku_env.py

should support newrelic monitoring

should support newrelic monitoring

should organize settings module better

settings module is organized so that there is global settings for all projects and project
settings for each specific project.

• global settings are updated by django-boilerplate itself
• project settings are updated by each specific project itself

The hierarchy structure:

• settings.common > project.common -> settings.dev -> project.dev
• settings.common -> project.common -> settings.prod -> project.prod
• settings.common -> project.common -> settings.stag -> project.stag

project.common is used to override settings.common
project.dev is used to override settings.dev
project.prod is used to override settings.prod
project.stag is used to override settings.stag

dev, prod and stag are settings for development, production and staging environment respectively