Snippet List
Most people simply wrap "from localsettings import *" in a try/except ImportError block. That's what I've done for years, but recently came up with this better way.
The problem this snippet solves is that if your localsettings.py itself causes an ImportError somehow, that error will be silently swallowed and your intended localsettings will be ignored. Instead, we use `imp` to first check if the module exists, then unconditionally try to import it.
- development
- staging
- production
- localsettings
All I wanted was for one to one compilation of coffeescript to javascript.
* Without special templatetags
* Without specifying explicit bundles
* Served dynamically in development
* Compiled by collectstatic for producton
This code is the minimum required for this.
There are two things to take into account:
* list method to find coffeescript files to compile for collectstatic
* find method to find coffeescript equivalent for a js file for django.contrib.staticfiles.views.serve.
The list method will use the list method on all finders that come before it in STATICFILES_FINDERS to find all the files that end with .coffee and will return the equivalent .js path with a storage class that knows how to compile the coffeescript.
The find method will use the find method on all finders that come before it in STATICFILES_FINDERS to locate the coffeescript file that is actually being requested.
It will then compile the coffeescript into a file in settings.CACHE_DIR before serving that file.
- development
- staticfiles
- coffeescript
- collectstatic
Originally based on: [http://djangosnippets.org/snippets/1872/](http://djangosnippets.org/snippets/1872/)
The way the original snippet formatted sql didn't work for mysql properly so I taught it to use the sqlparse python module. Now it looks like this when settings.DEBUG=True:
SQL executed:
SELECT "django_session"."session_key",
"django_session"."session_data",
"django_session"."expire_date"
FROM "django_session"
WHERE ("django_session"."session_key" = d326108d313a2e5c5fb417364b005ab9
AND "django_session"."expire_date" > 2011-04-08 14:54:13.969881)
took 0.001 seconds
SELECT "auth_user"."id",
"auth_user"."username",
"auth_user"."first_name",
"auth_user"."last_name",
"auth_user"."email",
"auth_user"."password",
"auth_user"."is_staff",
"auth_user"."is_active",
"auth_user"."is_superuser",
"auth_user"."last_login",
"auth_user"."date_joined"
FROM "auth_user"
WHERE "auth_user"."id" = 2
took 0.000 seconds
Additionally, this middlware is enabled conditionally based upon the url query string "debug". You can enable it for a single request by appending: ?debug=true to the url.
- middleware
- development
- debug
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
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
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
If your code is under source control and you develop locally and then publish that globally, you might need to modify the settings file after each update to ensure the system paths and database settings are correct.
This simple solution helps to distinguish development server from the public server. And you won't need to care about modifying files on the public server anymore.
Create a file called `dev_environment.py` in your `site-packages` directory of the development server only (do not put it under source control). Then use the following lines in the beginning of your files, you want to check whether you are in the development environment.
try:
from dev_environment import *
except:
is_dev_environment = False
Then for example, you can set the database settings according the environment:
if is_dev_environment:
DATABASE_NAME = "test"
DATABASE_USER = "root"
DATABASE_PASSWORD = ""
else:
DATABASE_NAME = "publicproject"
DATABASE_USER = "projectuser"
DATABASE_PASSWORD = "ahl3379ljkasd"
8 snippets posted so far.