Christopher Lawlor
Adventures in Freelancing
Hiding the Django Debug Toolbar in the Admin
Aug 18th
The Django Debug Toolbar is a an extremely helpful tool, but I find it a bit annoying in the admin. Thankfully, it only takes a few lines of code to blacklist the admin section.
Put this in your local_settings file (click the little ‘View Source’ icon in the upper right to easily cut & paste):
import re
def show_toolbar(request):
uri = request.get_full_path()
if re.match(r'/admin/', uri):
return False
return True
DEBUG_TOOLBAR_CONFIG = {
'SHOW_TOOLBAR_CALLBACK': show_toolbar
}
How to Quickly Open Virtualenvs on Windows
Jun 7th
I develop on both Windows and Linux. In fact, I often work on the same projects in both environments.
In general, I find both environments to be mostly the same, as far as Python development is concerned. Mostly the same that is, except that virtualenvwrapper isn’t available on windows.
If you’re not familiar with virtualenvwrapper, it is a brilliant shell script that makes virtualenv super easy to work with. I highly recommend it (except of course if you’re on Windows)
One of the best things about virtualenvwrapper is it lets you quickly and easily activate any available virtualenv with the `workon` command.
$ workon virtualenv_name (virtualenv_name)/path/to/project/dir/$
Not only does it activate the environment, but it will also automatically ‘cd’ you to the project’s working directory. You have to set the up manually but it is super simple, just add the ‘cd’ command to the ‘postactivate’ hook that virtualenvwrapper sets up in the virtualenv’s directory.
So, no virtualenvwrapper for Windows, but there are other ways to get a command shell which is already good to go for a given project.
In fact, it only takes a simple shortcut to cmd.exe with a few arguments. Create a new shortcut using the right-click context menu, then set
- Target: %windir%\system32\cmd.exe /k More >
Django How-To: Add Debugging Apps to Your Local Settings
Jun 3rd
There are some great debugging apps, like the django-debug-toolbar and django-command-extensions, that help out immensely while developing your next killer Django site. There’s a small catch to using them though, which is that they have to be added to INSTALLED_APPS. No big deal, but you don’t really want these installed and running in a production install.
Again, no big deal. It’s an old trick now to maintain a separate local_settings.py file. By importing our local_settings at the end of the settings.py module, anything in local_settings will overwrite whatever is in settings.
So all we have to do then is make a new list of debugging apps in local_settings.py, and add them to the INSTALLED_APPS list in settings.py.
My first naive attempt was to do this:
# local_settings.py
INSTALLED_APPS += ('django_extensions',)
Can you spot the problem? The original INSTALLED_APPS is not available in local_settings.py, so we can’t add to it there.
Well, if we can’t add our list in local_settings.py, let’s add in in settings.py
# local_settings.py
DEBUG_APPS = ('django_extensions',)
# settings.py
try:
from local_settings.py import *
INSTALLED_APPS += DEBUG_APPS
except ImportError:
pass
This works just fine, as long as there is a DEBUG_APPS list specified in local_settings.py. However, the whole point of having a local_settings.py file is to optionally add or overwrite settings.
To remove this dependency, More >
Setting Up Client Mercurial Repositories
May 24th
Hosting multiple mercurial repositories isn’t too tricky, there are various tutorials scattered around the web that will get you up and running. However, the security setups in these tutorials are somewhat lacking. This is particularly true if you need fine grained control over not only who gets to PUSH, but also who gets to PULL from the repositories.
Our goal here is to host as many repositories as we’d like, but only allow client access on a per-repository basis. If I set up repository A for client A, I don’t want client A to be able to pull from repository B.
Let’s start by describing our starting point. . All of the tutorials I’ve found get you set up with something like this. We’ve installed mercurial somewhere, and copied the hgwebdir.cgi file to our webroot, and configured it with a hgweb.config file.
Also, there is an .htaccess file at the web root that both limits POST and PUT access to users specified in a password file .htpasswd, which is made with the htpasswd command.
# .htaccess file at webroot
Options +ExecCGI
RewriteEngine On
# / for root directory; specify a complete path from / for others
RewriteBase /
RewriteRule ^$ hgwebdir.cgi [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule More >