# When Two Packages Fight for a Name

## Pillow, the [un]friendly fork of PIL.

Many of us have had the "pleasure" of working with a pair of forked projects. Normally, this is an exercise in patience and reading code with extreme precision, but sometimes it is a whole other level of frustration.

In particular, I have spent a lot of time banging my head on FFmpeg and Libav, both of which generally provide identically named shared libraries which provide identically named exports, but are slowly diverging and offer slightly different functionality. Perhaps I am a complete n00b, but I have found it anything but easy to anticipate which one I will get when I install or later call upon anything prefixed with "ffmpeg" or "av", let alone develop code against them.

Because of that, I was very concerned when I started taking a serious look at Pillow, the self-dubbed "friendly" fork of PIL. On the surface, I am in love with the project and its call to action. However, I am afraid of the project's assumption of the "PIL" namespace, and how that will inevitably break other code in interesting ways.

Pillow was originally conceived because PIL did not play well with package managers (or at least one of them). However, three years later, this no longers not seems to be the case; I can trivially pip install PIL or pip install something-that-requires-PIL and everything works as expected.

Ergo, what happens when tool "A" depends on PIL, tool "B" depends on Pillow, and your project depends on both A and B? Whichever of PIL or Pillow was installed last wins the right to be returned from import PIL, and breaks the reasonable assumptions of one of A or B.

We certainly need to deal with backwards incompatibilities within a single tool (PIL could just have easily gone on to v2.0.0 (and beyond) introducing its own differences), but it does not seem right for one project to take over the name of another.

It seems like the author of Pillow is conscious of these issues and is working towards fixing it, but like seemingly most of the Python community has decided that it is okay for the "friendly" fork to enact a hostile takeover of the name.

Posted . Categories: .