Add to this the merry dance you have to go through to ammend commit messages in Mercurial and things get even worse. (Oh how I’d love for hg to implement something similar to git’s $ git commit –amend )

Hence, a Pre-transaction-commit hook for hg that will ask me if I’m sure I want to commit without an issue number. If want to commit anyway, it’s just two extra keystrokes, and saves a whole lot of rollback/apply nonsense.

#!/usr/bin/env python
import os
import re
import subprocess
import sys
 
cmd = subprocess.Popen(['hg', 'log', '-vr', os.environ['HG_NODE']],
                       stdout=subprocess.PIPE).communicate()[0]
msg = cmd.split('description:')[1]
issue_regexes = [
    # Trac
    r'#\d+',
    # Redmine
    r'fixes #\d+',
    r'refs #\d+',
    ]
if not filter(lambda x: re.search(x, msg), issue_regexes):
    print "No issue ref or fix... message is:"
    print msg
    sys.stdout.write("Continue? [y/n] ")
    resp = raw_input().lower()
    if resp == 'n':
        sys.exit(9)

Then add the following to your project’s .hg/hgrc:

[hooks]
pretxncommit = path/to/your/pretxncommit.py

Saving you endless embarrassment:

davidmiller@pascal:~/src/buggy_repo$ hg commit -m "A context-less void"
No issue ref or fix... message is:
 
A context-less void
 
 
 
Continue? [y/n] n
transaction abort!
rollback completed
abort: pretxncommit hook exited with status 9

Love regards etc

This mode provides integration with the django management commands within emacs, as well as test integration, a minor-mode with syntax highlighting for editing templates, will determine whether you are using Fabric or Buildout, as well as much more!

This mode is under active development, so please file any bugs at the Github page, and feel free to provide any feedback/feature requests etc.

Current features include:

• Run dev server in an emacs buffer [C-c C-p r]
• * Checks to see if runserver_plus is available
• * If not uses in-built runserver
• Jump to current project in browser (start server if required) [C-c C-p b]
• Run test case at point in buffer [C-c C-p t]
• Run tests for current app in buffer [C-c C-p t]
• Run Syncdb on current project
• Management commands for current project in interactive buffer
• South integration – run south convert, schemamigration, migrate
• Run django shell in buffer [C-c C-p s]
• * Checks for shell_plus
• * If not defaults to shell
• Fabric integration [C-c C-p f]
• Startapp and dumpdata on current project within emacs
• Database integration with Emacs sql-mode interactive buffer [C-c C-c d
• Django Template minor mode with syntax highlighting for django

template tags

• Snippet collection for django
• generate tags table for project
• run manage commands in interactive buffer
• Buildout integration
• Generate TAGS table for project to enable quick navigation
• Jump to template at point or from editing view [C-c C-p g t]

Grab it while it’s hot!

Particularly with large test suites though, the speed increase is too large to go unnoticed (In my projects normally in the region of 150% YMMV).

And your tests can never be too fast right?

One solution to this is to only use the coverage test runner in a seperate management command. That way you always have access to the stats, but your ‘regular’ test run doesn’t take the performance hit.

Not only that, but you can also run the coverage stats on your continuous integration server once every few hours for a consistently recent picture of how your coverage is looking.

The code itself is nothing dead simple, just subclasses the django BaseCommand class and then fetches the right test runner:

"""
Run our tests with coverage turned on
"""
import sys
 
from django.core.management.base import BaseCommand
 
class Command(BaseCommand):
    """
    We totally want to get coverage details, but that's so slow!
    """
    option_list = BaseCommand.option_list
    help = "Run our tests with coverage turned on"
    args = "[appname ...]"
 
    requires_model_validation = False
 
    def handle(self, *tests, **options):
        """
        Actually do the test run
 
        Arguments:
        - `*tests`: test labels
        - `**options`: passed opts
        """
        verbosity = int(options.get('verbosity', 1))
        interactive = options.get('interactive', True)
        mod = __import__("django-test-coverage.runner")
        failures = mod.runner.run_tests(tests, verbosity=verbosity,
                                        interactive=interactive)
        if failures:
            sys.exit(bool(failures))

This then needs to live somewhere in an a management dir of one of your installed apps…

yourproject/yourapp/management/commands/coverage.py

…and you’ll need to

$ easy_install django-test-coverage

So that the test runner is there in your environment.

Grab the raw file here.

Alternatively you could patch django itself. Until they merge those changes though, I’ll be sticking with the seperate command.

I have just started using the Listen music player, which is a very nice lightweight little python program that comes shipped with xubuntu. As of the time of writing the version included in the xubuntu-desktop package has not been updated so that it integrates with last.fm properly.

The following fixes the problem, and will happily allow you to broadcast your terrible taste to the rest of the world without sitting you down & asking why you really want to do so.


wget http://www.listen-project.org/raw-attachment/ticket/826/audioscrobbler_manager.py

rm audioscrobbler_manager.py


You can see this in action on my last.fm profile should you have the inclination.

Love regards etc

Notice: The next post will almost certainly be of a less niche nature. Look forward to it. Or something.