Posts Tagged ‘python’

Mercurial Hook to ensure issue references in Trac/Redmine

Saturday, June 4th, 2011

As much as I love the version control integration of the bug trackers I use (Redmine and Trac) I find myself forgetting to include the issue reference more often than I’d like to admit.

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

Tags: , , , , , ,
Posted in something's burning, technical, wishful thinking | 1 Comment »

Announcing Pony Mode – a Django editing mode for Emacs

Saturday, May 28th, 2011

I’m pleased to announce the first beta ‘release’ of Pony Mode, a minor mode for working on Django projects in Emacs.

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!

Tags: , , , ,
Posted in favourite things, technical | 2 Comments »

coverage command for separate test runner in django

Friday, February 18th, 2011

I’m a long-time fan of django-test-coverage. It takes Ned Batchelor‘s coverage.py and wraps it in a django test runner for you, which is great.

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.

Tags: , , , , , ,
Posted in technical | 4 Comments »

howto: Enable Last.fm integration for Listen Music Player in Xubuntu/Xfce

Monday, December 15th, 2008

Notice: This is a technical post. If you don’t have this problem, you probably want to skip this one.

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

sudo cp audioscrobbler_manager.py /usr/lib/listen/

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.

Tags: , , , , , , , ,
Posted in technical | 28 Comments »