Python 3.8's Assignment Expressions, aka the Walrus operator, feel like an excellent pattern for checking optional environment variables that are only needed to initialize a library like Sentry.
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.
Everybody know about long spagetty-style settings file for django :-) I tried to find any cool settings loader, but have no luck.I created this one myself. Ok, we forgetting about `settings.py` and creating module settings (folder named settings with file `__init__.py`). This `__init__.py` file have preloader for modules placed in settings folder and `../settings_local.py` (if exists) at the end. settings_local is awesome tool, when you use any VCS like git and have settings in vcs, but for example you have different database connection settings. You can change this settings in settings_local. Settings splitter have variable moduleweights. This variable declares weights for selected modules to allow loader sort modules by priority and use already defined settings in each other loaded module. You can define your custom modules and weights there. Ok, now few examples. settings/env.py import os # Quick-start development settings - unsuitable for production # See https://docs.djangoproject.com/en/1.6/howto/deployment/checklist/ DEBUG = not 'http/ask.helldude.ru/' in os.path.realpath(__file__) settings/assets.py # Static files (CSS, JavaScript, Images) # https://docs.djangoproject.com/en/1.6/howto/static-files/ import os import sys settings = sys.modules['project.settings'] STATIC_URL = '/static/' STATIC_ROOT = os.path.join(settings.BASE_DIR, 'static') STATICFILES_DIRS = (os.path.join(settings.BASE_DIR, "project/static"),) STATICFILES_FINDERS = ( 'django.contrib.staticfiles.finders.FileSystemFinder', 'django.contrib.staticfiles.finders.AppDirectoriesFinder', 'compressor.finders.CompressorFinder', ) settings_local.py: import sys settings = sys.modules['project.settings'] print 'I WAS LOADED KHA KHA KHA' if settings.DEBUG: print 'In debug mode' You can see amazing 'hack' there :-) I use already defined settings via sys.modules['project.settings'] (where project is common folder for my project applications). I hope you like this small lifehack for django settings! rudude.
It took me some time to figure out how to set up logging in Django. What I want to do is to log to a pair of rotating files each 1MB in size. What I come up with is this code segment in the `settings.py` file.
This code allows you to register a model to Django that is only used for unit testing. It will not exist in the regular Django workflow. After the tests executed, the Django settings are restored. Usage: 1. Change `tests.py` into a `tests` package. 2. Place a `models.py` in the `tests` package. 3. Use the following code below to enable it. Example: class MyTest(CustomSettingsTestCase): new_settings = dict( INSTALLED_APPS=( 'django.contrib.contenttypes', 'django.contrib.auth', 'app_to_test', 'app_to_test.tests', ) ) Based on http://djangosnippets.org/snippets/1011/ as Django 1.4 version
These are my working settings for a postgress database on heroku, after they removed automatic inyection of the values.
Help setting up directories
By using map_path([directory_name]) you can avoid hard coding paths for a specific OS in your settings.py
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 %}
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/')
Very much like the snippet joshua wrote (http://djangosnippets.org/snippets/67/) for the same purpose but with the addition that this lets the user get values for more complex settings like dicts and lists
Read code for info
**Warning**: I'm quite sure this is **not** a best practice, but this snippet has proven being very useful to me. Handle with care. I also wonder about the impact on performance, while I didn't notice any slowdown on a very small app of mine. Idea is to expose project settings to template request context through a context processor, and \__doc__ should be self-explanatory. Of course, if you know a better way to achieve the purpose, please tell in the comments.
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()
This is a decorator which essentially replaces the decorated view with a view that always raises `Http404` (File Not Found) when `settings.DEBUG` is set to True.
39 snippets posted so far.