Question

Question

Is my approach to multiple Django settings.py files below reasonable (transparent, safe, etc.)?

My Approach

I have a settings.py and a settings_local.py. settings.py is under version control and a settings_local.py is NOT under version control. At the end of settings.py it tries to import settings_local.py if it’s available.

My theory to this approach is that I can leave my default / safe settings under settings.py and simply push to production to deploy. On deploy, settings_local.py won’t be present and its local-only settings are not used. However, when working locally settings_local.py is present and its local-only settings are used.

settings.py

DEBUG = False
MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
)
# other settings...

try:
    from settings_local import *
except ImportError:
   pass

settings_local.py

from settings import *

DEBUG = True
MIDDLEWARE_CLASSES += (
    'debug_toolbar.middleware.DebugToolbarMiddleware',
)
# other settings...

My concern about this approach is that they both import the other. I don’t think this qualifies as a circular import but as an indicator that under different circumstances one would consider combining these files.

The reason settings_local.py imports settings.py is so I can add to already defined variables while observing DRY principles e.g. add a new entry to MIDDLEWARE_CLASSES without completely redefining it.

Thanks!

---

Solution

Ultimately, I abandoned the above outlined approach. It was an interesting and informative process for me to try solving this problem, however, my amalgamated approach just has too many drawbacks.

For folks finding this in the future, the most appropriate approach is likely one of the solutions as outlined in the wiki page on this topic as kindly pointed out by @DrTyrsa and @Mark Lavin, thanks!

Answer 1

While this is a common approach it is not a good approach. I have used this type of configuration in the past and since abandoned it. The problem comes when you have multiple developers working together or when you are deploying to multiple environments (i.e. staging and production). You have the choice of either

1. Make settings.py the production settings. Then each developer must override settings to setup their local environment (DB settings, DEBUG=True, adding debug_toolbar, etc). Since this is not in source control it is repeated work and leads to “it works on my machine” kinds of problems.
2. Make settings.py the development settings. Now you have meaningful pieces of your production configuration in local_settings.py which is not in source control. This makes deployment messy. Obviously you don’t want to put sensitive information in the source control.

Adding a staging environment just makes this worse. I much prefer the Simple Package Organization for Environments described in the SplitSettings wiki.