Login

Tag "settings"

39 snippets

Snippet List

Globs for INTERNAL_IPS

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.

  • settings
  • debug
  • ip-addresses
  • internal-ips
Read More

TestSettingsManager: temporarily change settings for tests

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()

  • settings
  • test
  • syncdb
Read More

Load templatetag libraries via settings

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.*

  • templates
  • settings
  • tags
  • templatetags
  • conf
Read More

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

Use git log to give your app a revision

Put that stuff in your settings.py Then you can use the git log last date to make that your "revision number" assuming you don't use regular version release numbers. With it you can do something like: <div id="footer"> &copy; My Company &mdash; The Super App (revision {{ GIT_REVISION_DATE }}) </div> See if you like it

  • settings
  • subprocess
  • git
Read More

Different approach to local 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

  • settings
  • development
  • deployment
Read More

Keep settings.py in version control safely

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."

  • files
  • configuration
  • settings
  • development
  • debug
Read More

Include entire networks in INTERNAL_IPS setting

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!

  • settings
  • ip-addresses
  • cidr
  • internal-ips
Read More

Automagically import settings from installed applications

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.

  • settings
  • import
  • reusable
  • apps
  • applications
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