Hacker News Reader

Comment by flashingpumpkin | Hacker News Reader

I've got to disagree with the chapter about settings files. Instead of maintaining multiple different settings for different environments, make your default settings file pull modifications for each environment from os.environ, e.g.:

  STATIC_URL = os.environ.get('STATIC_URL', '/static/')

This is a lot saner and won't descend into a mess that is keeping multiple settings files around. It's also a lot easier to explain.

View on HN

Import a local_settings.py that isn't in the repository. Setting os environment variables and having multiple settings in the repository seems inflexible, a potential security problem, and just introduces unnecessary complexity to your application (doing different things because of a custom os environment variable). The security issue is production instructions in your main source repo, putting those instructions in a secured repo, hopefully maybe even encrypted, with limited access is probably more secure.

I use a version of that -- a single system variable identifying the environment and a series of conditional blocks for each environment in the settings.py file:

  ENVIRONMENT = os.environ.get('ENVIRONMENT', None)
  
  if not ENVIRONMENT in ('development', 'staging', 'production'):
      raise Exception('You need to set ENVIRONMENT variable')
  
  if ENVIRONMENT == 'development':
      # ...
  elif ENVIRONMENT == 'staging':
      # ...

Some further explanation on how we typically manage our settings files, http://lincolnloop.com/blog/2013/feb/15/django-settings-pari...

The environ trick is nice, and while it makes it harder to shoot yourself in the foot, it doesn't prevent it.

I have a strong preference for actual separate, situation-specific settings files. Mostly due to long, sorrowful experience debugging web server setups which were leaking environment variables across virtual hosts.

That's a very nice idea, but you would still end up with: start_debug.sh, start_prod.sh, etc

It is a good idea nonetheless, so you can inject the variables needed from the outside

start.sh debug

Reply on news.ycombinator.com