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?
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
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 http://dist.plone.org/thirdparty/ -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:
easy_install http://dist.plone.org/thirdparty/PIL-1.1.7.tar.gz
To include PIL in a buildout, either specify the egg with the same version pin or use a versions section:
[buildout]
parts =
find-links =
http://dist.plone.org/thirdparty/
eggs =
PIL
versions = 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.
Method 2
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.
Method 3
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.
Method 4
On Windows, I installed PIL in a virtualenv as follows:
Install PIL in your global python site-packages by executing the .exe from:
http://www.pythonware.com/products/pil/
Then, as a “do it yourself-er”, copy the PIL.pth file and PIL directory in C:Python25Libsite-packages to your virtualenv site-packages directory. Yeah, python is still a “get your hands dirty” environment…
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0