title: Is this approach to Django multiple settings files reasonable?
body: <h1>Question</h1>
  
  <p>Is my approach to multiple Django settings.py files below reasonable (transparent, safe, etc.)?</p>
  
  <h2>My Approach</h2>
  
  <p>I have a <code>settings.py</code> and a <code>settings_local.py</code>. <code>settings.py</code> is under version control and a <code>settings_local.py</code> is NOT under version control. At the end of <code>settings.py</code> it tries to import <code>settings_local.py</code> if it's available.</p>
  
  <p>My theory to this approach is that I can leave my default / safe settings under <code>settings.py</code> and simply push to production to deploy. On deploy, <code>settings_local.py</code> won't be present and its local-only settings are not used. However, when working locally <code>settings_local.py</code> is present and its local-only settings are used.</p>
  
  <h3>settings.py</h3>
  
  <pre><code>DEBUG = False
  MIDDLEWARE_CLASSES = (
      'django.middleware.common.CommonMiddleware',
  )
  # other settings...
  
  try:
      from settings_local import *
  except ImportError:
     pass
  </code></pre>
  
  <h3>settings_local.py</h3>
  
  <pre><code>from settings import *
  
  DEBUG = True
  MIDDLEWARE_CLASSES += (
      'debug_toolbar.middleware.DebugToolbarMiddleware',
  )
  # other settings...
  </code></pre>
  
  <p>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. </p>
  
  <p>The reason <code>settings_local.py</code> imports <code>settings.py</code> is so I can add to already defined variables while observing DRY principles e.g. add a new entry to <code>MIDDLEWARE_CLASSES</code> without completely redefining it.</p>
  
  <p>Thanks!</p>
  
  <hr>
  
  <h1>Solution</h1>
  
  <p>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. </p>
  
  <p>For folks finding this in the future, the most appropriate approach is likely one of the solutions as outlined in the <a href="https://code.djangoproject.com/wiki/SplitSettings" rel="noreferrer">wiki page on this topic</a> as kindly pointed out by @DrTyrsa and @Mark Lavin, thanks!</p>