The problem with installing PIL using virtualenv or buildout

Each Answer to this Q is separated by one/two green lines.

When I install PIL using easy_install or buildout it installs in such way, that I must do ‘import Image’, not ‘from PIL import Image’.

However, if I do “apt-get install python-imaging” or use “pip -E test_pil install PIL”, all work fine.

Here are examples of how I trying to install PIL using virtualenv:

# virtualenv --no-site-packages test_pil
# test_pil/bin/easy_install PIL
# test_pil/bin/python
Python 2.5.1 (r251:54863, Feb  6 2009, 19:02:12) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import PIL
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named PIL

I see, that easy_install pack PIL into the Egg, and PIP does not. Same thing with buildbot, it uses eggs.

How could I install PIL properly, using easy_install or buildout?

The PIL version packaged on pypi (by the author) is incompatible with setuptools and thus not easy_installable. People have created easy_installable versions elsewhere. Currently, you need to specify a find-links URL and use pip get a good package:

pip install --no-index -f -U PIL

By using pip install with the --no-index you avoid running the risk of finding the PyPI (non-fixed) original of PIL. If you were to use easy_install, you must use a direct link to the source tarball of a corrected version; easy_install stubbornly still uses the PyPI link over the find-links URL:


To include PIL in a buildout, either specify the egg with the same version pin or use a versions section:

parts =
find-links =
eggs =
versions = versions

PIL = 1.1.7

Edit March 2011: Fixes to address the packaging issues have been merged into PIL’s development tree now, so this workaround may soon be obsolete.

Edit February 2013: Just use Pillow and be done with it. 🙂 Clearly waiting for the original package to be fixed has not paid off.

Use Pillow: the “friendly” PIL fork 🙂 It offers:

  • Full setuptools compatibility
  • Faster release cycle
  • No image code changes that differ from PIL (i.e. it aims to track all PIL image code changes, and make none of its own changes without reporting them upstream.)
  • Windows binaries

If PIL ever does exactly what Pillow does, then the fork will die. Until that happens, we have Pillow.

DISCLAIMER: I am the fork author, and Pillow was created mainly to make my job easier (although it’s great to see other folks using it too).

EDIT: Pillow 2.0.0 was released on March 15, 2013. It offers Python 3 support and many bug fixes/enhancements. While we still attempt to track changes with upstream PIL, (unfortunately or fortunately depending on how you look at it) Pillow has begun to drift away from PIL.

For Ubuntu I found I needed to to install the C headers package for my python version (2.7)

sudo apt-get install python2.7-dev

Afterwards, pip install pil worked.

On Windows, I installed PIL in a virtualenv as follows:

Install PIL in your global python site-packages by executing the .exe from:

Then, as a “do it yourself-er”, copy the PIL.pth file and PIL directory in C:\Python25\Lib\site-packages to your virtualenv site-packages directory. Yeah, python is still a “get your hands dirty” environment…

The answers/resolutions are collected from stackoverflow, are licensed under cc by-sa 2.5 , cc by-sa 3.0 and cc by-sa 4.0 .