Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Try refactoring your settings to use a more object-oriented structure. A good example is outlined by [David Cramer from Disqus:</p> <p><a href="http://justcramer.com/2011/01/13/settings-in-django/" rel="nofollow">http://justcramer.com/2011/01/13/settings-in-django/</a></p> <p>You'll put any server-specific settings in a <code>local_settings.py</code> file, and you can store a stripped-down version as <code>example_local_settings.py</code> within your repository.</p> <p>You can still use separate settings files if you have a lot of settings specific to a staging or review server, but you wouldn't want to store complete database credentials in a code repo, so you'll have to customize the <code>local_settings.py</code> anyways. You can define which settings to include by adding imports at the top of <code>local_settings.py</code>:</p> <pre><code>from project.conf.settings.dev import * </code></pre> <p>Then, you can set your <code>DJANGO_SETTINGS_MODULE</code> to always point to the same place. This would be <em>instead</em> of calling <code>settings.configure()</code> as outlined in the Django docs:</p> <p><a href="https://docs.djangoproject.com/en/dev/topics/settings/#either-configure-or-django-settings-module-is-required" rel="nofollow">https://docs.djangoproject.com/en/dev/topics/settings/#either-configure-or-django-settings-module-is-required</a></p> <p>And that way, you know that your settings on your production server will definitely be imported, since <code>local_settings.py</code> is always imported.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload