Working with TurboGears is usually a breeze. But when it comes to installation thing never seem to go too well. Firstly do you run the tg_setup.py the project provides or easy_install TurboGears it? Why do you need to run the installer twice sometimes? There are answers in the mailing list to these questions but the fact these questions are asked gives me the willies.
I'm not having a go at the maintainers of the project. They are always extra helpful on the mailing list and to be fair if it really bothers me that much why don't I just fix it myself. I'm sad to say I can't be bothered, I've got more important things to do and I'm sure the maintainers have made the same decision.
Anyway, today I ran across a new one and couldn't find a solution via google so I'm offering up this snippet to the search engine in the sky.
After installing most of TurboGears I went to install Routes. I used easy_install but it didn't work.
easy_install "Routes >= 1.7" Searching for Routes>=1.7 Reading http://pypi.python.org/simple/Routes/ Reading http://routes.groovie.org/ Best match: Routes 1.7.1 Downloading http://pypi.python.org/packages/source/R/Routes/ Routes-1.7.1.tar.gz#md5=89cdc61ae803dc151c338ddd85551478 Processing Routes-1.7.1.tar.gz Running Routes-1.7.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-6ZoHjg/Routes-1.7.1/egg-dist-tmp-GXYrHm Traceback (most recent call last): ... File "/usr/local/tgmetalinfo/tgenv/lib/python2.5/ setuptools-0.6c7-py2.5.egg/setuptools/sandbox.py", line 29, in <lambda> {'__file__':setup_script, '__name__':'__main__'} File "setup.py", line 1, in <module> ImportError: No module named ez_setup
The first thing that struck me is that ez_setup is part of the setup tools package so how can it not be imported. To complicate things more I'm using workingenv which dicks about with your PYTHONPATH to create a sandbox.
After poking about on the easy_install site I found the answer in the docs. I created a file (in the current working directory) like this:
[easy_install] # set the default location to install packages install_dir = CWD/ENVIRONMENT FOLDER/lib/python2.5
where CWD and ENVIRONMENT FOLDER are replaced with your workingenv library path. Now the install works.
I think all of this has something to so with workingenv not creating a site-packages folder inside lib/python2.5 and something somewhere expecting it. Anyway, it all works for me now. Hope this helps.
PS: I know working env is deprecated in favour of virtualenv but I ran in to the same problem with virtualenv 
Anyway, to get to the point. There is a good google tech talk by one of the authors of VMWare Fusion. He goes in to the ins and outs of OSX development touching on the 'Apple creates API's for it's own needs' which I think most OSX developers know. For some reason embedding is disabled so here is the