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.
This TestSettingsManager class takes some of the pain out of making temporary changes to settings for the purposes of a unittest or doctest. It will keep track of the original settings and let you easily revert them back when you're done. It also handles re-syncing the DB if you modify INSTALLED_APPS, which is especially handy if you have some test-only models in tests/models.py. This makes it easy to dynamically get those models synced to the DB before running your tests. Sample doctest usage, for testing an app called "app_under_test," that has a tests/ sub-module containing a urls.py for testing URLs, a models.py with some testing models, and a templates/ directory with test templates: >>> from test_utils import TestManager; mgr = TestManager() >>> import os >>> mgr.set(INSTALLED_APPS=('django.contrib.contenttypes', ... 'django.contrib.sessions', ... 'django.contrib.auth', ... 'app_under_test', ... 'app_under_test.tests'), ... ROOT_URLCONF='app_under_test.tests.urls', ... TEMPLATE_DIRS=(os.path.join(os.path.dirname(__file__), ... 'templates'),)) ...do your doctests... >>> mgr.revert()
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.
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.*
A simple addition to the settings.py file of your project to allow you to easily specify entire network ranges as internal. This is especially useful in conjunction with other tools such as the [Django Debug Toolbar](http://github.com/robhudson/django-debug-toolbar/tree/master). After you set this up, the following test should pass test_str = """ >>> '192.168.1.5' in INTERNAL_IPS True >>> '192.168.3.5' in INTERNAL_IPS FALSE """ Requirements ------------ * The [IPy module](http://software.inl.fr/trac/wiki/IPy) Acknowledgements ---------------- Jeremy Dunck: The initial code for this idea is by Jeremy and in [Django ticket #3237](http://code.djangoproject.com/ticket/3237). I just changed the module and altered the use of the list superclass slightly. I mainly wanted to put the code here for safe keeping. Thanks Jeremy!
Allows you to include globs of IP addresses in your INTERNAL_IPS. It's shell-style glob syntax (the [fnmatch module](http://docs.python.org/library/fnmatch.html)). This should be helpful with the [Debug Toolbar](http://github.com/robhudson/django-debug-toolbar/tree/master), among other things. Like [#1362](http://www.djangosnippets.org/snippets/1362/), but with no external dependencies.
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.
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
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.
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.
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.
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/')
Read code for info
These are my working settings for a postgress database on heroku, after they removed automatic inyection of the values.
Help setting up directories