Login

Tag "settings"

39 snippets

Snippet List

Read settings from local_settings.py

Each installation of our Django site has slightly different settings -- namely, which database to use. Developers can provide a `local_settings.py` file which lets them override (or, just as usefully, extend) settings that are in `settings.py`. Subversion is told to ignore `local_settings.py`, so it's never checked in. If `local_settings.py` is missing, the site refuses to work. We include a `local_settings_example.py` file so that new developers can get started more quickly.

  • settings
  • development
  • deployment
  • deploy
  • production
  • local
  • local-settings
  • local-deployment
Read More

djangopath: conveniently set sys.path and DJANGO_SETTINGS_MODULE

In the past, whenever I had a script that I wanted to properly configure the settings for, I would use something like the following idiom at the top of the script: import sys, os; dirname = os.path.dirname # sys.path.insert(0, dirname(dirname(__file__))) sys.path.insert(0, dirname(__file__)) os.environ['DJANGO_SETTINGS_MODULE'] = 'myapp.settings' Notice that this is a relative setting to `__file__` variable in the script. The djangopath function is an attempt to do away with the above such that I can now write the following: from lib import djangopath; djangopath(up=2, settings='myapp.settings') This seems to work for me, but it assumes that you are packaging your script inside your projects/apps. If they are elsewhere then you may need to resort to another method (e.g. absolute paths, etc.) AK

  • settings
  • path
Read More

Dynamic Django settings context processor

Here's a nice way of easily passing only certain settings variables to the template. Because of the way Django looks up context processors, we need a little hack with sys.modules. The [blog entry is here](http://sciyoshi.com/blog/2008/jul/10/dynamic-django-settings-context-processor/).

  • dynamic
  • settings
  • context
  • processor
Read More

Decorator and context manager to override settings

Overriding settings ------------------- For testing purposes it's often useful to change a setting temporarily and revert to the original value after running the testing code. The following code doubles as a context manager and decorator. It's used like this: from django.test import TestCase from whatever import override_settings class LoginTestCase(TestCase): @override_settings(LOGIN_URL='/other/login/') def test_login(self): response = self.client.get('/sekrit/') self.assertRedirects(response, '/other/login/?next=/sekrit/') The decorator can also be applied to test case classes: from django.test import TestCase from whatever import override_settings class LoginTestCase(TestCase): def test_login(self): response = self.client.get('/sekrit/') self.assertRedirects(response, '/other/login/?next=/sekrit/') LoginTestCase = override_settings(LOGIN_URL='/other/login/')(LoginTestCase) On Python 2.6 and higher you can also use the well known decorator syntax to decorate the class: from django.test import TestCase from whatever import override_settings @override_settings(LOGIN_URL='/other/login/') class LoginTestCase(TestCase): def test_login(self): response = self.client.get('/sekrit/') self.assertRedirects(response, '/other/login/?next=/sekrit/') Alternatively it can be used as a context manager: from django.test import TestCase from whatever import override_settings class LoginTestCase(TestCase): def test_login(self): with override_settings(LOGIN_URL='/other/login/'): response = self.client.get('/sekrit/') self.assertRedirects(response, '/other/login/?next=/sekrit/')

  • settings
  • decorator
  • contextmanager
Read More

easy absolute path for settings.py

when you deploy djangos apps, some servers have problems resolving the absolute path of some files (e.g: sqlite3 + lighttpd + apache), using the snippet above solves this issue :)

  • settings
Read More

Default settings for a app

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.

  • settings
  • conf
  • app
Read More

tag to store a settings value as template variable

Get any value from settings.py as a template variable. The variable can then be used in conditional tags. E.g. to show a link to a help page only if it the help page url is defined in settings.py {% load get_setting %} {% get_setting MY_HELP_URL as help_url %} {% if help_url %}<a href="{% help_url|safe %}">Help</a>{% endif %}

  • template
  • tag
  • templatetag
  • settings
Read More

change settings locally in an individual test

So you need to change some settings when running an individual test in a test case. You could just wrap the test between `old_value = settings.MY_SETTING` and `settings.MY_SETTING = old_value`. This snippet provides a helper which makes this a bit more convenient, since settings are restored to their old values automatically. Example usage: class MyTestCase(TestCase): def test_something(self): with patch_settings(MY_SETTING='my value', OTHER_SETTING='other value'): do_my_test()

  • settings
  • testing
  • unittest
Read More

Load local settings

If you have a production, staging, testing and development environment, you might want to have a global checked in (in your version control system) settings.py for production + a local settings.py to override various settings (like database connection). It's also good for development, since developers don't - by incident - commit to the production settings.py, since they can use their local settings, that should be ignored (.cvsignore, .svnignore or similar).

  • settings
Read More

Conditional INSTALLED_APPS entry

Some INSTALLED_APPLICATIONS applications may not be critical for your website to work - for example you may only need them for development - like 'django_extensions' or 'debug_toolbar'. They needn't be installed actually for the site to work. This way you can avoid discussions with other developers if some application should be included, or is it just spam, because if they don't like it, they don't have to install it. On a production server you can leave this not installed, to avoid security concerns like a possibility to IP-spoof and see the debug toolbar.

  • configuration
  • settings
  • conditional
  • installed_apps
Read More