Why Zero-Install Will Succeed

Also known by the longer title: I Sure Hope Zero-Install Succeeds, Or Else We Might All Give Up On Package Managers Entirely.

If you’ve tried to run any of my software lately, you may have noticed that it’s all distributed and packaged via Zero-Install. I’ve posted about how awesome it is, but that was just an initial impression - I’m now familiar enough with the system to expand on those impressions.

After reading that the distros have killed python yesterday, I felt compelled to write in a little more detail how zero-install solves this and many other problems right now, across platforms and languages, and for much less effort than the current packaging practices.

In the open-source world, you’ve got two types of package / dependency managers: system-based and language-based.

System based:

Think apt, yum, etc. Practically all linux systems come with a package manager, it’s one of the great strengths of the open-source development model. Typically, these systems require root access to install a new package, and packages are global - you can’t have two different minor versions of python installed at once¹, because they would live in the same place and overwrite each other.

This works well enough for distributions, because every release cycle they carefully coordinate versions of each and every package such that there are no conflicts. But this is impossible for you, the end user, if you decide you’d like to use the latest version of python - the rest of your system depends on the packaged python, so it simply won’t let you install a newer one.

Language-based:

python-setuptools, rubygems, ivy, etc. These are mainly used by developers, for developers. They solve some of the system-based package managers’ problems (like installing multiple concurrent versions, and not requiring root access), but they have problems of their own. And what’s worse, they usually only work when you’re dealing with exactly one language. Your python egg can’t depend on a ruby gem, and I presume there’s not actually any way to package a hybrid application that spans multiple languages with such systems.

And every time someone makes a new language, they write a new package manager that’s often completely at odds and incompatible with your system package manager. Not to mention your poor users having to learn how to operate your chosen package manager (I’m looking at you, cabal).

What’s the result?

Most library developers will use the package manager for their language-of-choice, because it’s usually easier. You can often host these wherever you like, and most centralised systems have no actual approval process - you can distribute your new package instantly. But taking this route means that someone will have to package your library again if they want to use it in a system-based package manager.

Most applications that are meant for end-users have little choice but to provide system packages. That typically means at least deb, rpm, and whatever smaller systems you want to support. That’s a lot of packaging, and declaring dependencies according to each system - some of which may not even have the dependencies you require, because nobody bothered to package them for that specific system. And it’s not just different distributions - specialised packages / dependencies are sometimes needed even between different releases of the same distribution.

That’s a lot of work, and a lot of testing required to ensure your package will actually function on all of these systems. And then there’s the extra work required to actually get your package installed into the distribution’s repository - something that I perceive to be so much work that I’ve never even attempted it for the small utilities I write².

And after all that work, windows and mac users are usually still left out, so you will want to provide two different self-contained installers if you want to support those platforms too.

Gee, that sounds like an awful lot of work!

It does. Packaging is a big job, and most developers don’t see it as much fun. I have the utmost respect for distro packagers with the patience to keep such a large number of packages up to date without conflicts, but that doesn’t mean I want to have to rely on them - all too often you’re completely out of luck until the new version of your favourite software has actually been packaged for your favourite distribution (unless you want to built it from source - good luck!).

The solution, which I gave away in the very first sentence of the post, is of course Zero-Install. Specifically, for these reasons:

• Anyone can install software - no root access required
• Package implementations live in a cryptographically-unique namespace, meaning multiple versions of the same package can always be installed without conflict if they are both needed
• It works cross platform - windows support is still young, but it should already work on all *nix/BSD style distros including Mac OSX
• It’s decentralised - anyone can host zero-install packages, and you can depend on a zero-install dependency regardless of where it comes from on the internet
• It doesn’t fight your system package manager - it can re-use system packages instead of installing its own, and there’s a trivial process for freezing a particular zero-install package into .deb (or .rpm, etc) format - allowing system packages to depend on zero-install packages if needed

That’s not even all the features, but they’re certainly the most compelling reason to stop packaging for both system and language-specific package managers. As a software developer, if you only have the time/patience/knowledge to package for one system, you might as well make it the one that will work in the overwhelmingly largest number of situations with the least amount of effort³. I’ve looked around, and I’m pretty convinced that zero-install is without a doubt that system.