#!/bin/sh
rm -v django/utils/unittest/*.py*
wget http://hg.python.org/unittest2/archive/tip.tar.gz -O unittest2.tar.gz
tar --wildcards --no-wildcards-match-slash --strip-components=2 --directory=django/utils/unittest -xf unittest2.tar.gz unittest2-*/unittest2/*.py
rm -v unittest2.tar.gz
sed -i 's/^from unittest2/from django\.utils\.unittest/' django/utils/unittest/*.py
echo "unittest2 updated"

Run it from the root of the svn checkout.

If you have a models file like this (artificial, but play along):

from django.db import models
from random import random
rand_val = random()

class MyModel(models.Model):
    r = rand_val

After you import MyModel in some other module, you can’t re-load the class definition of MyModel.

You might think that calling reload() on models would do the trick. What actually happens is:

• models.py is reloaded (the file is executed again)
• so models.rand_value changes…
• but models.MyModel.r does not!

Classes that inherit from models.Model seem to be immortal singletons. I tried removing them from sys.modules as arthurk is doing. I tried deleting all references to the variables in my code. The first instance came back every time, even though python was shown to be reloading the module and re-executing the code within.

In most use cases, this is exactly what you want. It usually would be inefficient to have multiple copies of MyModel available in different parts of your code.

Unfortunately, I needed multiple instances for testing purposes. I ended up settling for a less comprehensive testing solution.

I’ve never had any trouble like this with my mail service before. Don’t use Ontrac.

I spent a bunch of time setting up and configuring VMs with test environments. I can now test in Ubuntu, OS X, Windows, and have a couple of configurations for each of those. I don’t have every possible supported combo, but it’s a good start. I spent more time than I should have messing with virtualenv. I still don’t have automated scripts to do everything I need, but I’m not going to invest more time in that right now.

I also spent a while becoming acquainted with the details of how tests are actually run. I’ve done some modification of the test runner to fix some of the hard-coded paths, but it’s still not working the way I want it to. I think that in the end, the right thing to do is probably to leave the existing test infrastructure as-is, and then move everything to the new consolidated single test directory at the end of the project, after the tests are cleaned up and moved to unittests. The alternative is to move them one at a time as I get them cleaned up, but then we’ll have to have some interm test running code that checks both options. I think it’s probably best to leave my branch as close to trunk as possible so that patches can go back and forth as improvements are made.

I need to update the documentation on contributing to include a note that new patches should use unittests not doctests.

So in summary – not a lot of committed code, but a bunch of work that should make things more productive for next week.

Unit tests will make it quicker to pinpoint exactly what is causing a test to fail. Moving each test case into its own function may reveal bugs that were concealed or glossed over as a side effect of the existing test case environment in the doctest. As I’m working through the code, I’ll be looking out for tests which are doing inefficient things. Developers run the tests regularly, and runtimes can vary from 10 minutes to over an hour depending on hardware and database configuration. By speeding them up, I’ll be saving countless future developer-hours.

dd if=/dev/disk1 of=/dev/disk2 conv=noerror,sync bs=64k

(obviously you will need to specify the correct disk devices for your setup)

Using the larger block size resulted in a speed increase from 7MB/s to an average transfer speed of 37MB/s. It makes a big difference when you’re copying a full 1.5 TB!

During the install, I kept my php and svn config files, since the diff showed no major changes to the ones in the package (other than my configurations, of course).

The first problem was that the Postgresql 8.3 databases needed to be updated to 8.4, and the installer doesn’t do that. I made sure to run these before the installer removed the 8.3 package (it asks before doing so at the end of the install script), though I don’t know if that is strictly necessary. The upgrade was relatively simple:

#see what clusters you currently have
pg_lscluster

#upgrade your existing cluster
sudo pg_upgradecluster 8.3 main /var/lib/postgresql/8.4/main


The upgrade command SHOULD take care of copying the data, upgrading it to the new format, stopping the old cluster, and starting the new cluster on the same port. On one of my machines the process of stopping the old cluster failed, but doing it manually with pg_ctlcluster worked.

Once I upgraded the Postgres databases, I allowed the script to remove the old packages and reboot the machine. Then I selected the kernel upgrade in the slicehost control panel (which rebooted the machine again) and let it come up. Almost everything worked perfectly.

The other issue I encountered was that after the upgrade, memcached no longer started on reboot. After a bit of poking around, I discovered that the upgraded package that comes with 9.10 comes with a new file in /etc/default/memcached which defaults to having memcached disabled. To enable it, set ENABLE_MEMCACHED=yes and memcached starts when your server boots. This does have a launchpad bug, but nobody seems to be taking responsibility for fixing it.

Another gotcha turned out to be the fact that memcached must already be running when Django starts. I only resolved the issues with memcached after my Django processes had started on the other server, and it took me a few minutes to remember that I needed to restart them to fix caching.

The only other minor issue was that (as expected) the upgrade overwrote my script that gets invoked whenever svnserve is called. I have this in place so that I can svn+ssh into the server and check files out without specifying their absolute path in the file system. My script looks like this:

#!/bin/sh
umask 002
exec /usr/bin/svnserve.bin -t -r [path to svn repo] "$@"


I keep the actual svnserve binary (default installed to /usr/bin/svnserve) in svnserve.bin and the script in svnserve.ssh. I then link /usr/bin/svnserve to svnserve.ssh, so when svn gets upgraded, I just recopy the binary and re-link.

To fix this, add alias php='/usr/local/php5/bin/php' to your ~/.bash_profile and re-login. Now when you run php from the command line, it will use version 5, which you can verify by running php -v.