5 ms·

The Perfect Django Settings File

33 points by Uncle_Sam 16y ago

redsymbol 16y ago
Good writeup. One small thing I do differently: in my dev machines, I'll set and export DJANGO_DEBUG in the environment. Then in settings.py: import os DEBUG = 'DJANGO_DEBUG' in os.environ This doesn't hardcode a single hostname in checked-in code, and works well across different machines and developers.
njharman 16y ago
This is far from perfect. Using old style DATABASE settings. Questions article's up to dateness and author's knowledge. Importing local_settings into settings like that means it's hard for local settings to add to the various lists e.g. installed apps, middleware. It's far more flexible to import a base_settings.py into settings.py (which is the local settings file). OA's templete thing is (if I understood it correctly) total fail. Learn about django.template.loaders.app_directories.Loader Debug status based on domain name is not scalable, prone to error and annoying (I often need to switch debug on/off in dev/staging/production(pre-launch))
- jsdalton 16y ago
  I agree with some of your comments, but to be fair this was posted in October 2009, so it's almost one year old. If I'm not mistaken, the new dictionary-style DATABASES setting is from 1.2, which only came out this year. Not sure I agree about your comment regrading settings. It's quite easy to amend values from the main settings instead of overwriting them, you just do e.g. from settings import INSTALLED_APPS, then INSTALLED_APPS += ( ... ). That said, I've found the approach to settings outline here: http://blog.zacharyvoase.com/2010/02/03/django-project-conventions/ http://blog.zacharyvoase.com/2010/02/03/django-project-conve... to be quite intriguing and have been meaning to investigate it and possibly start using it.
zalew 16y ago
if socket.gethostname() == 'your.domain.com': DEBUG = False No. The default setting should be False, and set True only for dev.
jokull 16y ago
You should be able to throw a key-value store on top of settings to override certain values at runtime. Replace django.conf with django_dynconf?
mgrouchy 16y ago
one thing that I do a little differently is the template dirs I just do a standard TEMPLATE_DIRS = ( os.path.join( PROJECT_ROOT, "templates", ), ) for the template dirs and the I symlink in template directorys of apps in the project. This allows me to do any additional template wackiness(like adding another directory in the path outside the project) with a symlink rather then modifying the settings file
richardhenry 16y ago
Yikes! if socket.gethostname() == 'your.domain.com': DEBUG = False ? This is just bad advice. I prefer to be explicit in the settings for each environment, and create a settings package, with the following modules: - common - development - staging - production Then in each of the non-common modules import the common variables, and set your DJANGO_SETTINGS_MODULE depending on the environment. virtualenv makes this particularly easy. Here's a writeup by Zachary Voase, who I've had the pleasure of working with more than once: http://blog.zacharyvoase.com/2010/02/03/django-project-conventions/ http://blog.zacharyvoase.com/2010/02/03/django-project-conve...
anhtran 16y ago
I feel much better with the signals you have raised. But I think if you have many effects on settings you will lose the bright property of Django. Everything should start from the simplest things.
kilian 16y ago
This is how I do my debug, seems a little more compact :) DEBUG = socket.gethostname() != 'your.domain.com' I'd also suggest you add ADMINS = ( ('name', 'your-email@domain.com'), ) and # Email-settings SERVER_EMAIL = 'your-email@domain.com' if DEBUG: EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend' else: EMAIL_HOST = 'localhost' EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend' So you get notified of any errors via e-mail when debug is off.
tvon 16y ago
I go for having a settings module which imports different things depending on what's available. For example, you can define host-specific settings based on hostname for different production servers (or production, staging, QA, etc), or just a 'local.py' for development. Regardless of what's imported, that file starts with "from base import *" which is where the main settings are. For the curious, since everyone has their own way of doing this, my new-project init script is here: http://github.com/tvon/gig http://github.com/tvon/gig
BerislavLopac 16y ago
I prefer using a separate settings_local.py, which overrides certain settings like DEBUG and the like. Then each environment can easily have its own settings_local file, excluded from code versioning.

33 points by Uncle_Sam 16y ago

Good writeup. One small thing I do differently: in my dev machines, I'll set and export DJANGO_DEBUG in the environment. Then in settings.py: import os DEBUG = 'DJANGO_DEBUG' in os.environ This doesn't hardcode a single hostname in checked-in code, and works well across different machines and developers.

njharman 16y ago

This is far from perfect. Using old style DATABASE settings. Questions article's up to dateness and author's knowledge. Importing local_settings into settings like that means it's hard for local settings to add to the various lists e.g. installed apps, middleware. It's far more flexible to import a base_settings.py into settings.py (which is the local settings file). OA's templete thing is (if I understood it correctly) total fail. Learn about django.template.loaders.app_directories.Loader Debug status based on domain name is not scalable, prone to error and annoying (I often need to switch debug on/off in dev/staging/production(pre-launch))

jsdalton 16y ago
I agree with some of your comments, but to be fair this was posted in October 2009, so it's almost one year old. If I'm not mistaken, the new dictionary-style DATABASES setting is from 1.2, which only came out this year. Not sure I agree about your comment regrading settings. It's quite easy to amend values from the main settings instead of overwriting them, you just do e.g. from settings import INSTALLED_APPS, then INSTALLED_APPS += ( ... ). That said, I've found the approach to settings outline here: http://blog.zacharyvoase.com/2010/02/03/django-project-conventions/ http://blog.zacharyvoase.com/2010/02/03/django-project-conve... to be quite intriguing and have been meaning to investigate it and possibly start using it.

zalew 16y ago

if socket.gethostname() == 'your.domain.com': DEBUG = False No. The default setting should be False, and set True only for dev.

jokull 16y ago

You should be able to throw a key-value store on top of settings to override certain values at runtime. Replace django.conf with django_dynconf?

mgrouchy 16y ago

one thing that I do a little differently is the template dirs I just do a standard TEMPLATE_DIRS = ( os.path.join( PROJECT_ROOT, "templates", ), ) for the template dirs and the I symlink in template directorys of apps in the project. This allows me to do any additional template wackiness(like adding another directory in the path outside the project) with a symlink rather then modifying the settings file

richardhenry 16y ago

Yikes! if socket.gethostname() == 'your.domain.com': DEBUG = False ? This is just bad advice. I prefer to be explicit in the settings for each environment, and create a settings package, with the following modules: - common - development - staging - production Then in each of the non-common modules import the common variables, and set your DJANGO_SETTINGS_MODULE depending on the environment. virtualenv makes this particularly easy. Here's a writeup by Zachary Voase, who I've had the pleasure of working with more than once: http://blog.zacharyvoase.com/2010/02/03/django-project-conventions/ http://blog.zacharyvoase.com/2010/02/03/django-project-conve...

anhtran 16y ago

I feel much better with the signals you have raised. But I think if you have many effects on settings you will lose the bright property of Django. Everything should start from the simplest things.

kilian 16y ago

This is how I do my debug, seems a little more compact :) DEBUG = socket.gethostname() != 'your.domain.com' I'd also suggest you add ADMINS = ( ('name', 'your-email@domain.com'), ) and # Email-settings SERVER_EMAIL = 'your-email@domain.com' if DEBUG: EMAIL_BACKEND = 'django.core.mail.backends.console.EmailBackend' else: EMAIL_HOST = 'localhost' EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend' So you get notified of any errors via e-mail when debug is off.

tvon 16y ago

I go for having a settings module which imports different things depending on what's available. For example, you can define host-specific settings based on hostname for different production servers (or production, staging, QA, etc), or just a 'local.py' for development. Regardless of what's imported, that file starts with "from base import *" which is where the main settings are. For the curious, since everyone has their own way of doing this, my new-project init script is here: http://github.com/tvon/gig http://github.com/tvon/gig

BerislavLopac 16y ago

I prefer using a separate settings_local.py, which overrides certain settings like DEBUG and the like. Then each environment can easily have its own settings_local file, excluded from code versioning.