matt good

I've fixed up a couple of things in Evolution that have been irritating me for a while using filters to pipe the messages through external apps.

New message notification

I've wanted to have popup notifications when I get new messages, so I wrote a little Python script that parses the message and displays a summary using Galago:

Installation

• Download Ka-Ping's scrape.py library to somewhere on your PYTHONPATH (usually /usr/lib/python2.4/site-packages; change the version number if necessary)
• Download mail-notify.py and make it executable (chmod a+x mail-notify.py)
• Add your Evolution filter (use Browse to pick the file if it's not on your PATH):

Working spam filtering

Spam filtering in Evolution used to work, but in recent versions I have not seen it catch a single spam. At first it seemed like this was due to not having SpamAssassin installed. After installing that it starts the spamd process and thinks for a little bit when I try to mark messages as junk, but still nothing gets caught.

So, I gave up on the built-in filtering and set up an Evolution filter using Bogofilter:

Unfortunately Evolution doesn't provide a way to just specify a program to run when you click the Junk and Not Junk buttons, so I'm using Spam Trainer to train Bogofilter. You can drag messages from Evolution into Spam Trainer to mark them as "spam" or "ham".

Set your Spam Trainer preferences to use the Bogofilter program:

Subversion includes a contrib script svn_apply_autoprops.py that scans your auto-props settings and applies them to a working copy. These are normally applied to files you add to the repository, but this script is useful if you have added new properties, or other users have added files without configuring the desired properties. However, since I use SVK this script didn't work for me. I looked at the script to see if I could convert it to use SVK instead, but it was relying on the .svn folders to try to determine what directories to scan and I didn't like the fact that they were parsing the config by hand with regular expressions instead of using the extremely useful ConfigParser module.

I decided it would be quicker to rewrite the script than to fix up the existing one, so here is the new and improved version: svn_apply_autoprops.py

Key features include:

Faster

This version is about twice as fast as the old one on the several repositories I've tested. The old version walked the directory structure for each pattern to find matching files. This version uses svn status -v to find all the versioned files once and simply scans this list to find the matching files.

Simpler

Using the ConfigParser and simplifying the directory scanning made this new version about 1/2 the code of the old one.

SVK

There's a variable that is defined at the top of the script to determine which command is used: svn or svk. Both support the same arguments needed by this script and are easily interchangeable.

It's been nearly a year since 0.8 was released, but after resolving over 400 tickets, some major refactoring, and adding plugin support Trac 0.9 is finally available, so get downloading!

Once you've upgraded you'll probably want to check out some plugins:

WebAdmin

Everyone will probably want to install this. It adds a web interface for those administrative tasks you used to use trac-admin for, plus you can even use it to install new plugins, or manage which components are enabled from your existing plugins.

Bitten

Bitten is a "Continuous Integration" build server. It monitors your code repository for updates and will automatically run build and testing scripts to make sure you know when a build was broken. You can run your builds on multiple target platforms and generate historical graphs of unit test results and code coverage.

LDAP Plugin

I haven't tried this one out yet, but it should be useful for administrators that use LDAP to authenticate users, since it now also allows you to manage permissions based on LDAP groups, or even store Trac permission information directly in LDAP.

Account Manager

This is one that I wrote that allows users to register a new account. It currently supports htpasswd or htdigest files, but it is extensible for storing accounts in other formats.

Trac Hacks

Trac Hacks is a site that offers hosting for Trac extensions and will be a good place to look for new plugins, since hopefully the development interest will grow now that the new release has been made final.

I've repackaged my account management module as a plugin and uploaded it on TracHacks.

Installation instructions are included in the README file in the source. It's a pretty simple process: run setup.py to build the Egg and copy it into your Trac environment.

The next step is to extend the webadmin interfaces to provide a frontend to configure the account manager settings.

Well, PythonEggs sounded like a neat idea, and now they've made it possible to turn Trac's pluggable framework into a real plugin system. Simply stick your extensions into an Egg, create a "plugins" directory in your environment, and drop-in the file.

Jonas is developing a webadmin module for Trac as a plugin, and I took his example and have repackaged my account management module. Turning it into a plugin was quite trivial, but there are a couple of other things I'd like to clean up tomorrow before I release it.

The Trac documentation should be updated soon to explain how to make plugins.

Well, after hacking around a bit I've gotten Snurf backported to Python 2.2 so that it will run on my host.

Snurf writes out the blog to static HTML and RSS pages, which is kind of nice. I'll have to check on turning on the comment capability, though I'll need to decide how I want to do the templates for that.

Update: I've imported all my old posts from the previous PyBloxsom blog. Here's the little Python script I wrote to convert them: pybloxsom2snurf

(http://dev.rubyonrails.com/about_trac)

Who needs Python marketing when Ruby On Rails runs their development site on a Python-based web application?

For those not familiar with Trac it's a combination of wiki and bug-tracking for software development projects. I use it at work and help out as a developer on it in my spare time. And of course it's all written in Python.

I'm trying to convince the other developers that we should include the "Python Powered" logo as an easter egg in the next release. There's nothing quite like having your competitor do your advertizing for you.

I just finished my first major use of Python testing tools. I just wrote a patch for Trac to add groups support to its fine grained permissions.

As I started writing the patch I was having trouble wrapping my head around all the different possibilities for conflicting rules and how they should take precedence. I started testing a few of them by hand, but I quickly realized that making sure that I covered all the scenarios was going to be difficult. Thankfully there were some examples in the code for using doctest.

Once I had figured out a couple of things about using doctest, I found it was the first testing tool I've actually enjoyed using. Doctest allows you to write your tests as basic textual documentation, then insert snippets from the Python command line. Doctest will run the command line sections and make sure that the output matches the document. This makes it incredibly easy to write tests, and the tests are quite readable and useful as examples.

On a sidenote, I got a complimentary copy of the Python Cookbook today. They contacted me a while back about using some submissions I had made on the cookbook website, but when they released the list of included recipies none of my submissions seemed to be included, so I wasn't expecting to receive a copy of the book. I actually considered picking up a copy at PyCon, but now I'm glad I waited.

The guys from Divmod were here at PyCon and today the gave a little talk about their service.

The basic functionality of their site is to provide a way to collect your email, rss, calendars, etc. into one place and they'll catalog it for easy searching and relating the information together.

They also provide VoIP service and can keep a log of your calls which is tied into the same address book information from your email, etc. Apparently they'll soon be able to let you specify rules about different people trying to contact you, so that email or calls from certain people are important and always go through, or others can get directed to voice mail. This can even be set up to be on a schedule so that people could only get in contact with you during business hours, or other similar rules.

The thing that I found most interesting is that they're working on determining information about references to dates for scheduling appointments. They claim that they'll be able to pick up on phrases like "next Thursday" and determine prompt you if you want to create an appointment about the meeting that you were discussing.

Today at PyCon I went to the talk on the Roundup Issue Tracker to see what I could learn from them for use in Trac.

One thing that I realized would be good is to add a QuickStart document for getting the built-in tracd up and running with minimal configuration. As the Trac user base is growing, the installation questions are growing. I think that there are still going to be a lot of people who want to use Trac via Apache. However, I think that if people can get tracd up and running quickly there will be less people that get stuck with nothing running. This should give them a chance to play with Trac a bit, rather than getting hung up on the Apache config right at the beginning and asking a bunch of questions that they'd figure out on their own in a minute if they had a running Trac server.

The feature of Roundup that seemed interesting is their use of email for issue reporting and discussion. This has been requested in Trac several times, but I haven't yet seen a good proposal on the format these emails should have. I liked that Roundup would use the CC list on emails to add new people to the so-called "nosy" list that is notified of changes.

Roundup also supports hook scripts similar to the idea I proposed on the Trac mailing list. I think that this would be a nice way to provide extension points for customizing the Trac event model.

During the talk I had decided I wasn't going to bring up Trac, since I didn't really want to come across as rude by promoting a competing application. However, during the Q&A time following the talk someone asked about Subversion integration. Richard (Rick?) indicated that he thought you could write some shell scripts, etc. to tie the two together, but didn't have a really good answer. So, of course at that point I had to put in a little plug for Trac. Some of the Mac people were taking notes on SubEthaEdit and put the site URL up on there, so I'm hoping some people will check it out.

Best quote of the conference:

When all you have is a hammer screws are stupid