Save this as conf.py in the app's directory. Now you can do `from myapp.conf import settings`. You can access from the imported object every item of your settings.py including the default settings of myapp. Though you don't have to define every setting in settings.py you use in your app. Now you can ommit annoying try...except statements to define defaults directly in the code.
Changes settings file according to server hostname.
Place this snippet at the bottom of your settings.py file, and if a local_settings.py file is present in the directory, all settings in that file will override those in settings.py
I like to keep all local settings files in my versioning repository. The way I differentiate between them is by querying the hostname of the local machine. I've got a host_settings folder with local settings files. Notice that the local settings file names go by a convention where '.' is replaced with underscores. Example: host_settings/local_machine_tld.py
Use this snippet at the end of your main settings.py file to automagically import the settings defined in each app of `INSTALLED_APPS` that begins with `APPS_BASE_NAME`. Set `APPS_BASE_NAME` to the base name of your Django project (e.g. the parent directory) and put `settings.py` files in every app directory (next to the `models.py` file) you want to have local settings in. # works in the Django shell >>> from django.conf import settings >>> settings.TEST_SETTING_FROM_APP "this is great for reusable apps" Please keep in mind that the imported settings will overwrite the already given and preceding settings, e.g. when you use the same setting name in different applications. Props to [bartTC](http://www.djangosnippets.org/users/bartTC/) for the idea.
This is an example how to use relative paths in settings file, but still keep settings readable.
In your settings file: TEMPLATE_TAGS = ( "djutils.templatetags.sqldebug", ) Make sure load_templatetags() gets called somewhere, for example in your apps __init__.py *Edit: Updated to work with templatetag libraries that use certain critical django-bits.*
Here is a trivial way to keep your Django project in shared version control or in a public repository without exposing settings that could have security implications, and without needing to modify settings.py for your local test or production environments on checkout. This is also a way to separate development settings from production settings, or to deploy the same code on multiple servers while only changing one site-specific "dotfile."
Useage: `{% load setting %}` `{% setting DEBUG %}` or... `{% setting MEDIA_ROOT %}` You get the gist.
39 snippets posted so far.