Jan 12

Version String Management in Python: Introducing python-versioneer

What’s a good way to manage version numbers in a Python project? I don’t mean:

  • where should it be stored, so that other code can find it. PEP 8 tells us to use __version__, and distutils tells us to call setup() with a version= argument. The embedded string is particularly useful to report or record a version in bug reports.
  • what format it should take: PEP 386 describes a format (N.N[.N]+[{a|b|c|rc}N[.N]+][.postN][.devN]) that enables comparison, so packaging tools can evaluate things like “dependency > 1.2.0”. (I happen to find this format really limiting, and this tool doesn’t necessarily produce PEP386-compliant strings, but that’s not what this post is about)

What I do mean is:

  • how does the right version string get into the code?
  • what does a release manager need to do when it’s time to make a new release?

The traditional approach, ages old, is to have a static string embedded in the code. Each time you’re about to make a new release, you make a commit which updates this string. It’s nice and simple, but has some problems: Continue reading →

Sep 11

London Jetpack Workshop coming up: September 29th

If you’re in the London area, check out the free workshop we’re hosting on writing addons with Jetpack. It’s happening on a Thursday night (September 29th) at City University. See Jeff’s blog post for details and signup. We’re also setting one up for the San Francisco area in October.. stay tuned.

I’ll be leading a session on using modules. See you there!


Aug 11


Hi! My name is Brian Warner. Welcome to my blog!

I’ve been working at Mozilla for about a year and a half. Before Mozilla I was at a startup (now gone) named AllMyData.com, which ran an online backup service aimed at home users and small businesses. For the backend, we developed an open-source encrypted distributed filesystem named Tahoe-LAFS (still thriving), with the relatively-unique feature of “provider-independent security”: the servers hold ciphertext, and only your client (and anyone you choose to share them with) holds the decryption key. By relying upon the servers for availability but not security, you can use servers that you wouldn’t trust otherwise. The system is designed with “POLA” in mind, the Principle Of Least Authority, which improves safety by giving each component as little power as possible; just enough to do its one job.

Mozilla’s Sync system, which helps keep your bookmarks and other browser data synchronized between multiple browsers, uses the same principle. The data is encrypted before it leaves your computer, and our servers don’t get to see the key. The similarity in philosophy between Sync and Tahoe was a big part of the reason I joined Mozilla: I had found a bunch of like-minded people with whom I could promote these ideas, with a wider audience (400 million users and counting!) than anything our tiny startup could reach. Shortly after joining, I helped build the credential-exchange protocol that Sync uses to add a new computer to your account (the “copy this code” J-PAKE-based dialog panel).

But most of what I’ve been doing for the last 18 months is Jetpack, now better known as the Add-On SDK. It’s a new way to tackle the admittedly painful process of writing add-ons for Firefox (and eventually other XUL-based programs, like Thunderbird).

Add-ons in Firefox have always been a bit.. organic. There’s an awful lot of internal interfaces, and add-ons authors have had to dig through a lot of that to find a useful point to attach or override some code. It’s messy, and fragile: it’s difficult for the Firefox developers to keep those internals stable while making large-scale improvements to the browser, so add-on authors are fighting an uphill battle to maintain compatibility with newer releases. With our new faster release cadence (every couple months!), the problem becomes even more challenging.

Jetpack was intended to make the simple things simple. It has a library of interface modules for doing common add-on tasks, like creating a UI, and modifying web pages. We, the SDK authors, will keep updating these modules to match the Firefox internals, so add-on authors won’t have to. One of the promises of Jetpack is that the high-level add-on code doesn’t need to change much at all to keep up with newer browsers.

The SDK has two parts: this library of modules, and a program that assembles your code with the right set of modules and produces the XPI file, ready for installation or upload to AMO. If you think about it in terms of gcc and other compilers, this program is a linker: it figures out which modules are required and combines them into an executable bundle.

The linker is written in Python, and since that’s been my dominant language for the last ten years, most of my Jetpack work has been on the linker side. I’ve also been heavily involved in developing the security model, to make Jetpack-based addons safer in the face of bugs and compromises. I’ll be explaining a lot more about the security model in this blog over the coming months.

And no description of Jetpack is complete without also mentioning Flightdeck, better known as the Add-On Builder. This is an online IDE for writing add-ons. On the backend, it runs a copy of the SDK to generate the XPIs. It allows folks to get into the add-on writing business without downloading or installing an SDK: just start writing the code! A big goal of Jetpack is to make add-on writing accessible to a wider developer community, leveraging Javascript skills that web-devs already have, and an online tool like Builder removes a lot of the unnecessary hurdles for that audience.