Slaptijack Title

Tech Messages | 2010-08-26

by Scott Hebert

Green NetworkA special extended edition of Tech Messages for 2010-08-20 through 2010-08-26:

Basic Django WSGI Handler

by Scott Hebert

Django LogoCreating a basic Django WSGI handler is pretty straightforward. The Django docs version is OK, but it relies on your application being part of the PYTHONPATH.

This is what I do instead:

import os
import sys

from django.core.handlers.wsgi import WSGIHandler

sys.stdout = sys.stderr
sys.path.insert(0, os.path.abspath(os.path.dirname(__file__)))
os.environ["DJANGO_SETTINGS_MODULE"] = "settings"
application = WSGIHandler()

This basic handler sets the path for us so that the application can be installed in a different environment without causing problems. It assumes that the WSGI handler is in the top level directory of your application (the same directory as your settings file). It also puts the application directory first in the list. This should have the effect of insuring that modules that come with your application are loaded instead of the system-wide version.

VirtualBox 3.2.8 Released

by Scott Hebert

VirtualBox LogoOracle’s VirtualBox 3.2.8 has been released. This is a maintenance release that mainly focuses on bug fixes rather than new features. Although I don’t think the changes in this release are as prolific as the fixes in 3.2.6, it’s definitely worth downloading.

One key feature buried in the Changelog is the ability to attach one disk to several virtual machines. This is especially useful in clustered setups where multiple machines share a single filesystem.

If you haven’t tried VirtualBox yet, I recommend it to anyone that has a need for a virtualized environment. It’s great for developers who need to support different platforms and system administrators who need a compact test environment.

Your Django manage.py ImportError May be a Syntax Problem

by Scott Hebert

Django LogoBackground: While cleaning up my development directory the other day, I renamed one of my Django project directories to the domain name of the site. For the sake of argument, we’ll call it django.slaptijack.com. When I descended into the directory and tried to start the development server, I received the following garbage:

$ ./manage.py runserver
Traceback (most recent call last):
  File "./manage.py", line 11, in 
    execute_manager(settings)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/management/__init__.py", line 436, in execute_manager
    setup_environ(settings_mod)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/core/management/__init__.py", line 419, in setup_environ
    project_module = import_module(project_name)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/utils/importlib.py", line 35, in import_module
    __import__(name)
ImportError: No module named django.slaptijack.com

If you’re like me, this probably shocked the heck out of you. My first thought was that there was some setting somewhere that controlled the name of the project or the primary project module or something. The answer was pretty easy, though.

Django assumes the top-level directory (the one with manage.py) is the primary module. The rule is that Python module names can only consist of letters, numbers, and underscores. This is pretty obvious when you think about how you can invoke methods of modules using dot notation. By replacing my dots with underscores in the directory name, I was able to successfully start up the development server.

Tech Messages | 2010-08-20

by Scott Hebert

Green NetworkInteresting technology-related news from around the web for 2010-08-20: