Login

Tag "settings"

Snippet List

localsettings

I'm using this to store settings in a thread-safe manner on mod_wsgi multithread deployment. The idea is to import `from localsettings import localsettings` instead of doing `from django.conf import settings` and use it as you would use normal settings, with the difference that you can alter settings for the current thread with a middleware (think of altering SITE_ID). Warning: altering settings is not officially supported and can lead to thread problems.

  • settings
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

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

Overwrite some views in settings.py

If you app defines some URLs with a name, and you want to overwrite this at project level with a different view you can use this snippet. You only need to change on line in the application code (the import statement).

  • urls
  • settings
  • reverse
Read More

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

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

change SITE_ID on fly

Django SITE_ID is a global setting, so the site framework requires you to run multiple instances of Django; at least one for each site. But i want have one instance for multiple sites. This snippet solve this task by change SITE_ID on fly. /sorry my bad english/

  • settings
  • site_id
  • site-contrib
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

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

Load a local settings file for dev/test environments

Add the snippet to your settings.py. If you have a settings_local.py it will load that one. Can be used in development environments where you might have different settings for your dev sandbox. You should exclude settings_local.py from SVN. By Rudy and Ed Menendez

  • settings
  • environment
  • production
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

3rd Party App Directories

How to make this work: * Put the code into your settings.py (or even better, local_settings.py if you have one) * Put 3rd party apps you'd like to use into the directories specified in APP_DIRS. * Place 'appname', into INSTALLED_APPS. Just a little trick I use to keep from having to install apps via setup.py; I can just stick apps into arbitrary locations and use them. I also do this to keep single copies of 3rd party apps I use in multiple projects (but again without installing to the global python path). No idea if this is bad practice or anything, but I find it useful.

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

39 snippets posted so far.