6

In the process of trying to write a Python script that uses PIL today, I discovered I don't seem have it on my local machine (OS X 10.5.8, default 2.5 Python install).

So I run:

easy_install --prefix=/usr/local/python/ pil

and it complains a little about /usr/local/python/lib/python2.5/site-packages not yet existing, so I create it, and try again, and get this:

TEST FAILED: /usr/local/python//lib/python2.5/site-packages does NOT support .pth files error: bad install directory or PYTHONPATH

You are attempting to install a package to a directory that is not on PYTHONPATH and which Python does not read ".pth" files from. The installation directory you specified (via --install-dir, --prefix, or the distutils default setting) was:

/usr/local/python//lib/python2.5/site-packages

and your PYTHONPATH environment variable currently contains:

''

OK, fair enough -- I hadn't done anything to set the path. So I add a quick line to ~/.bash_profile:

PYTHONPATH="$PYTHONPATH:/usr/local/python/lib/python2.5"

and source it, and try again.

Same error message.

This is kindof curious, given that PYTHONPATH is clearly set; I can echo $PYTHONPATH and get back :/usr/local/python/lib/python2.5. I decided to check out what the include path looked like from inside:

import sys
print "\n".join(sys.path)

which yields:

/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python25.zip /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5 /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-darwin /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-mac /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-mac/lib-scriptpackages /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-tk /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload /Library/Python/2.5/site-packages /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/PyObjC

from which /usr/local/python/yadda/yadda is notably missing.

Not sure what I'm supposed to do here. How do I get python to recognize this location as an include path?

UPDATE

As Sven Marnach suggested, I was neglecting to export PYTHONPATH. I've corrected that problem, and now see it show up when I print out sys.path from within Python. However, I still got the TEST FAILED error message I mentioned above, just with my new PYTHONPATH environment variable.

So, I tried changing it from /usr/local/python/lib/python2.5 to /usr/local/python/lib/python2.5/site-packages, exporting, and running the same easy_install command again. This leads to an all new result that at first looked like success (but isn't):

Creating /usr/local/python/lib/python2.5/site-packages/site.py
Searching for pil
Reading http://pypi.python.org/simple/pil/
Reading http://www.pythonware.com/products/pil
Reading http://effbot.org/zone/pil-changes-115.htm
Reading http://effbot.org/downloads/#Imaging
Best match: PIL 1.1.7
Downloading http://effbot.org/media/downloads/PIL-1.1.7.tar.gz
Processing PIL-1.1.7.tar.gz
Running PIL-1.1.7/setup.py -q bdist_egg --dist-dir /var/folders/XW/XWpClVq7EpSB37BV3zTo+++++TI/-Tmp-/easy_install-krj9oR/PIL-1.1.7/egg-dist-tmp--Pyauy
--- using frameworks at /System/Library/Frameworks
[snipped: compiler warnings]
--------------------------------------------------------------------
PIL 1.1.7 SETUP SUMMARY
--------------------------------------------------------------------
version       1.1.7
platform      darwin 2.5.1 (r251:54863, Sep  1 2010, 22:03:14)
              [GCC 4.0.1 (Apple Inc. build 5465)]
--------------------------------------------------------------------
--- TKINTER support available
--- JPEG support available
--- ZLIB (PNG/ZIP) support available
*** FREETYPE2 support not available
*** LITTLECMS support not available
--------------------------------------------------------------------
To add a missing option, make sure you have the required
library, and set the corresponding ROOT variable in the
setup.py script.

To check the build, run the selftest.py script.
zip_safe flag not set; analyzing archive contents...
Image: module references __file__
No eggs found in /var/folders/XW/XWpClVq7EpSB37BV3zTo+++++TI/-Tmp-/easy_install-krj9oR/PIL-1.1.7/egg-dist-tmp--Pyauy (setup script problem?)

Again, this looks good, but when I go to run my script:

Traceback (most recent call last):
File "checkerboard.py", line 1, in import Image, ImageDraw ImportError: No module named Image

When I check what's now under /usr/local/python/ using find ., I get:

./lib ./lib/python2.5 ./lib/python2.5/site-packages ./lib/python2.5/site-packages/site.py ./lib/python2.5/site-packages/site.pyc

So... nothing module-looking (I'm assuming site.py and site.pyc are metadata or helper scripts). Where did the install go?

I note this:

To check the build, run the selftest.py script.

But don't really know what that is.

And I also noticed the "No eggs found" message. Are either of these hints?

martineau
  • 119,623
  • 25
  • 170
  • 301
Weston C
  • 3,642
  • 2
  • 25
  • 31
  • 1
    Did you export the `PYTHONPATH`? Just setting it as a shell variable doesn't help. Try `export PYTHONPATH="$PYTHONPATH:/usr/local/python/lib/python2.5"` and use `env` to check it is really exported to the environment. – Sven Marnach Dec 09 '10 at 00:44
  • Huh. OK, I definitely need suggestions for a good primer on understanding shell/environment variables and commands like `env` and `export` and `source` better. I'd gladly take suggestions. This is only part of the problem, though... now that I've followed Sven's suggestions, the path seems to be getting recognized in `sys.path`, but I'm still getting the 'test failed' message from easy install. I'll update my question to reflect this. – Weston C Dec 09 '10 at 01:00

2 Answers2

4

You are using the Apple-supplied Python 2.5 in OS X; it's a framework build and, by default, uses /Library/Python/2.5/site-packages as the location for installed packages, not /usr/local. Normally you shouldn't need to specify --prefix with an OS X framework build. Also beware that the setuptools (easy_install) supplied by Apple with OS X 10.5 is also rather old as is the version of Python itself.

That said, installing PIL completely and correctly on OS X especially OS X 10.5 is not particularly simple. Search the archives or elsewhere for tips and/or binary packages. Particularly if you are planning to use other modules like MySQL or Django, my recommendation is to install everything (Python and PIL) using a package manager like MacPorts.

Ned Deily
  • 83,389
  • 16
  • 128
  • 151
1

Why did you specify --prefix in your easy_install invocation? Did you try just:

sudo easy_install pil

If you're only trying to install PIL to the default location, I would think easy_install could work out the correct path. (Clearly, /usr/local/python isn't it...)

EDIT: Someone down-voted this answer, maybe because it was too terse . That's what I get for trying to post an answer from my cell phone, I guess. But the gist of it is perfectly valid, IMHO: if you're using --prefix to specify a custom install location with easy_install, you're kind of 'doing it wrong'. It might be possible to make this work, but the easy_install documentation has a section on custom installation locations that doesn't even mention this as a possibility, except as a small tweak to the virtual python option. I'd suggest following the OS X instructions if you want to install to a custom location on a Mac, --prefix just does not seem like the right tool for the job.

evadeflow
  • 4,704
  • 38
  • 51
  • 1
    I generally like to keep packages/libraries that come with a default install separate from the ones I install, particularly if it's stuff I'm new to, and usually it's fairly practical to do so. If it turns out to be less than practical with Python, maybe I'll give up on the idea. – Weston C Dec 09 '10 at 02:18
  • 1
    @WestonC, depending on your needs, you may be better served using [virtualenv](http://virtualenv.readthedocs.org/en/latest/) to keep 'your' Python modules separate from the system-installed modules. The vast majority of packages install just fine if you do `python setup.py install` from within a virtualenv. For those packages (like PyQt) that don't play nice with virtualenvs, you can almost always work around this using a hack like the one described in [this answer](http://stackoverflow.com/questions/1961997/is-it-possible-to-add-pyqt4-pyside-packages-on-a-virtualenv-sandbox#8160111). – evadeflow May 28 '14 at 22:23