8 ms·

I've got to disagree with the chapter about settings files. Instead of maintaining multiple different settings for different environments, make your default set

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.

raverbashing 14y ago
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
- DrJ 14y ago
  start.sh debug
weirdcat 14y ago
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': # ...
btipling 14y ago
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.
ipmb 14y ago
Some further explanation on how we typically manage our settings files, http://lincolnloop.com/blog/2013/feb/15/django-settings-parity-youre-doing-it-wrong/ 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.
ubernostrum 14y ago
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.

raverbashing 14y ago

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

DrJ 14y ago
start.sh debug

weirdcat 14y ago

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': # ...

btipling 14y ago

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.

ipmb 14y ago

Some further explanation on how we typically manage our settings files, http://lincolnloop.com/blog/2013/feb/15/django-settings-parity-youre-doing-it-wrong/ 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.

ubernostrum 14y ago

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.