There is indeed a better way: Structured Settings. Turn the usual pattern of having settings.py import local_settings.py upside down. Call your specific setting (you can specify it be altering the DJANGO_SETTINGS_MODULE environment variable in your virtualenv activation script) and it will import the main settings (which you rename to base.py). This is documented in http://www.slideshare.net/jacobian/the-best-and-worst-of-django which is the slides of a presentation by one of the "fathers" of django.
1) create a settings folder in your project. 2) copy settings.py into it, rename it to base.py, and remove the import of local_settings. 3) copy local_settings.py into it and have it import * from base.py 4) make as many copies as you need different environments. My default settings start out like this (this is default_settings.py with dots where there should be white space so that nesting is preserved) # this system uses structured settings.py as defined in http://www.slideshare.net/jacobian/the-best-and-worst-of-django > # > # this third-level staging file overrides some definitions in staging.py > # You may wish to alter it to agree with your local environment > # > > from staging import * # get most settings from staging.py (which in turn, > imports from base.py) > > # # # now override the settings which came from staging # # # # > > # choose a different database... > # sqlite > DATABASES = { > . 'default': { > .. 'ENGINE': 'django.db.backends.sqlite3', > .. 'NAME': 'db.sqlite3', > . } > } > > DATABASE_ROUTERS = [] # turn off second database > > # Make a unique unique key just for testing, and don't share it with anybody. > SECRET_KEY = 'mlfs33^s1l4xf6a36$0#j%dd*sisfoi&)&4s-v=91#^l01v)*j' > > I have gone a step further by altering my manage.py to more easily call multiple settings files, and to remind me which one I am using at any moment. My present version of manage.py looks like this: > #!/usr/bin/env python > # encoding=utf-8 > from __future__ import print_function > import os > import sys > > if __name__ == "__main__": > . # altered for new settings layout > . if not any([arg.startswith('--settings=') for arg in sys.argv]): > .. os.environ.setdefault("DJANGO_SETTINGS_MODULE", > "formhub.settings.default_settings") > .. print('Your environment > is:"{}"'.format(os.environ['DJANGO_SETTINGS_MODULE'])) > . > . from django.core.management import execute_from_command_line > . > . execute_from_command_line(sys.argv) > > On Wednesday, September 18, 2013 11:36:17 PM UTC-6, Victor Hooi wrote: > > Hi, > > I have several settings in my Django settings.py file that are specific > > Currently, I'm grabbing these from environment variables in settings.py: > > import os >> ... >> # TODO - We need to gracefully catch if these aren't set. >> SOME_VARIABLE = os.environ['SOME_VARIABLE'] > > > This includes things like API keys, database IPs, database > username/passwords, static file locations etc. > > I then set these in the virtualenv activate script. > > Is this a good practice in Django? > > Also, is there a graceful way of catching when these aren't set? > Currently, I'm using some of those settings variables in models.py, and > it's failing silently. Should I put each os.environ call in a try/except > block, or is there a more Pythonic way? > > Cheers, > Victor > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. For more options, visit https://groups.google.com/groups/opt_out.
