Using Travis-CI for testing Galaxy Tools

Travis CI is one of the best things to happen to GitHub in some time - it adds automated testing capabilities to your source code repository as changes are committed, and even on pull requests to help ensure new work doesn't break existing functionality.

We've been using this for Biopython for over a year, but this month I've started using TravisCI for testing my add-ons for the Galaxy Project as well. My Galaxy tools (see also Cock et al. 2013) were already being tested every night once uploaded to the Galaxy Tool Shed, and I always stage releases via the Galaxy Test Tool Shed before posting them on the main Galaxy Tool Shed. However this fixed nightly schedule isn't very flexible for debugging failures.

Galaxy BLAST tools:

Galaxy sequence analysis tools:

I've currently got TravisCI working for my two Galaxy tool repositories on GitHub. Both configurations follow the same basic approach, which I have tried to explain in this post, and run the tests as soon as I update GitHub.

Pixelated Posters at Potatoes in Practice

Yesterday I attended the annual "Potatoes in Practice" meeting for the first time, mainly to see the finished display which I helped produce. Here it is, showing the twelve chromosomes of potato, drawn as stylized uniform green 'X' shapes, with different colour LEDs marking traits of interest for potato breeding.

Potato chromosomes 1 to 6, and 7 to 12, with LEDs marking traits of interest

My contribution was the background images, which are actually drawn using the bases of the potato genome instead of pixels. For this I wrote a little Python script to render photos using A, C, G and T from a FASTA sequence file, using Biopython to load the sequences, the Python Imaging Library (PIL) to load the photos, NumPy to manipulate the array, and ReportLab to render a PDF.

Potato chromosomes 9 and 10

Close-up showing the A, C, G, T pixels

Markup support for a Python project

Mark-up languages allow you to write a plain text input file which is then processed to produce a nicely formatted output - as HTML, PDF or similar. The plain text nature of the input is perfect for tracking under version control software, which other richer formats are not suited to. So what's the current best markup choice for a Python project? It looks like reStructuredText (*.rst).

Random access to blocked XZ format (BXZF)

I've written about random access to the blocked GZIP variant BGZF used in BAM, and looked at random access to BZIP2, but here I'm looking at XZ files which are based on LZMA compression. This was prompted by the release of Python 3.3 which includes the lzma module to support XZ files, which I then back-ported to offer lzma for Python 2.6 or later. Over the Christmas / New Year break I extended this to handle Blocked XZ Format (BXZF for short), so publishing this post is a bit overdue.

Free for non-commercial academic use only sucks

Scientific software released for free under an "academic only"/"non-commercial" licence really irks me, even if the source code is included. This is mainly because it isn't open source, and I believe science should be open, but this also causes a whole lot of headaches. Right now I'm particularly disappointed by the GATK licensing debacle from The Broad Institute - and I'm not alone in this, for example Mick Watson has just blogged about why the GATK re-licensing matters and there has been plenty of comment on Twitter.