Scott Blomquist

Like most good geeks, there are a few things about which I’m a little bit obsessive-compulsive. The desire to bring order to chaos is probably the same thing that attracted me to software in the first place.

One of my strongest compulsions is to want to keep my hard disk squeaky-clean. Don’t get me wrong—I’m really bad at it just like everyone else. But I like to feel like I at least have control over what’s on my hard disk. Every time I install a new piece of software, something inside me worries about whether it added some untracked file that won’t be automatically cleaned up if I ever decide to uninstall the software.

I remember back in the old days, when this compulsion was even more, umm, relevant due to hard disk size constraints. The best you could do for installing the latest whiz-bang software from freshmeat.net was “./configure.sh && make && make install”. Good luck figuring out what files that sprinkled all over your file system, when the time comes to later clean them up by hand.

The General Rise of Package Management

The good news is that things have come a very long way since then. Most Linux distributions have package managers that can conjure up almost any software that you might want with just a few keystrokes. With approximately the same number of keystrokes, you can reverse the installation and rest assured that your disk has been restored to at least close to its initial state.

And it’s not just operating systems that have package managers these days. It’s becoming a de facto requirement for programming languages to have a solid package manager as well. Perl has CPAN, C# and the other .NET languages have NuGet, Ruby has gem, and Python has PyPI.

Every perl whiz knows about CPAN—it’s been around for more than 15 years, and is probably one of the largest contributors to perl’s historical success. Same for Rubyists and gem. Hell, most developers of any sort know about those two package managers even if they’ve never touched perl or ruby as languages. On the other hand, it’s shocking to me how often I encounter a python user who doesn’t understand all of the tips and tricks for making the best use of Python’s equally robust package management tools and distribution ecosystem.

Python Package Management, Specifically

Python has had its own package repository for a very long time.

There seem to be two widely used package management tools in the world of Python. easy_install is the better known one for at least two reasons: 1) it has been around longer, and 2) it is preinstalled with nearly every python distribution (for example, it appears to ship with Mac OS, and is available as part of a default python install on Ubuntu 10.10).

Despite its ubiquity, it’s disqualified from receiving my enthusiastic support because it is incapable of uninstalling packages. (Remember how I started this post off complaining about how that shortcoming makes me twitchy?)

Fortunately, there’s a package manager for Python that does support uninstallation in addition to installation. Its name is pip. (It looks like it may be the case that pip is good for other reasons, too.)

Using pip

To get started with pip, you probably first need to install it. To do that, you’ll bootstrap using the package manager that you probably already have installed:

sudo easy_install pip

Now that you have pip installed, you probably want to install a package or two:

sudo pip install simplejson

sudo pip install e

And to uninstall later if you decide you don’t want them:

sudo pip uninstall simplejson

(You should keep the ‘e’ package—it’s very slick! More on this later.)

Uninstalling pip

I don’t really understand why you would want to do this, but because you installed pip using a package, you can use pip to uninstall it:

sudo pip uninstall pip

For bonus points, you can use pip to uninstall easy_install as well. (I understand even less why you would want to do this, but this actually came up on Stack Overflow.):

easy_install pip
pip uninstall pip setuptools

Other pip tricks

I’ve got a few other Python tricks up my sleeve in pip’s neighborhood (there’s virtualenv, and remember the ‘e’ package above?) which we’ll talk about next time.