Google induced Myopia

I’ve been working on an application which provides a graphical interface for embedding Creative Commons licenses in audio files, specifically MP3 right now. The previous iteration, a command-line application, used the eyeD3 library for handling the ID3 metadata embedded in the files. Unfortunately, we wanted to add the ability to handle ID3v2.2 in addition to 2.3 and 2.4 to the application, and eyeD3 doesn’t support ID3v2.2.

After some work in everyone’s favorite index of everything, Google , I stumbled on a promising candidate: PyId3v2 (now named PyTagger). Long story short, while PyTagger did most of what I needed, it seemed to be tagging in a way that was inconsistent with eyeD3 (and, it seems, the “standards”, as they are). That’s when I remembered the Python Package Index, or PyPI . I had run into references to PyPI while packaging Canterbury’s improvments to LoginManager and PySamba using the standard Python packaging mechanism, distutils .

Distutils, for all of it’s warts and flaws, does a passable job at packaging Python extensions, modules and, er, packages. Starting in Python 2.3 (I think), it also allows you to define additional meta-data about your extension, and auto-magically register it with the Python Package Index. In a way, it’s supposed to help create a distributed CPAN . And it presents a browsable archive, organized by target audience, topic area and the other pieces of meta-data distutils collects. Which is where I found a forked version of PyId3 , which not only has support for the types of tags I need to embed, but also has an interface which is, well, Python-ic (for lack of a better word).

Google had suggested PyId3, but the “original” version doesn’t support ID3v2.3 or 2.4. The whole incident has reminded me of one thing: the best tool overall is not always the best for a specific need. And while Google will remain one of my oft-used tools for Internet searching, I’ll remember PyPI now when I’m looking for a specific type of Python module.