Maybe it is time to consider using virtualenv. Virtualenv creates self-contained python environments
using the python version you specify. After activating the new virtual environment, everything you install using pip goes under that environment. This helps avoid situations like the one you described.
E.g. create and activate a new python environment using the default python:
# create environment
$ virtualenv --distribute myproject
New python executable in myproject/bin/python
Installing distribute...done.
Installing pip...done.
# activate environment
$ . ./myproject/bin/activate
# check default python
(myproject)$ which python
/Users/me/myproject/bin/python
It is suggested to use the --distribute
options to indicate that distribute should be used for installing packages in the new environment instead of (the older) setuptools. After activation your command prompt changes to indicate which python environment is active.
Now install some package. The files will go into myproject directory:
# install django
(myproject)$ pip install django
...
# search for django dir
(myproject)$ find myproject -iname django
myproject/lib/python2.7/site-packages/django
Finally, deactivate:
# deactivate and check for default python
(myproject)$ deactivate
$ which python
/usr/bin/python
To create an environment using a non-default version of python:
$ virtualenv --distribute -p /path/to/custom/python mynewproject
By default virtualenv will copy to the new environment any packages installed for the python version you use to bootstrap it. To prevent this and create an empty environment use the --no-site-packages
option. This is especially useful to create environments which can be exactly replicated e.g. from development to production.
Update: As of version 1.7 --no-site-packages
has become the default behaviour of virtualenv.
If you want more details, there are plenty of tutorials and blog posts online. E.g.:
- Notes on using pip and virtualenv with Django. (most of the post is not django-specific)
- Working with virtualenv.
Give it a try and I'm sure you'll stick with it.
Note: Make sure that your executable scripts do not have the python interpreter hardcoded. I.e. their first line should be #!/usr/bin/env python
and not something like #!/usr/bin/python
.
Not a good answer here, but I wanted to leave a note confirming that I encountered this exact same issue on a ~fresh Mountain Lion install.
There is some interesting discussion at the link below which suggests a controversial bug between the MacVim and Python configure files ... but making the suggested change in the config file did not work for me (assuming I did it right).
https://stackoverflow.com/questions/6490513/vim-failing-to-compile-with-python-on-os-x/8276426#8276426
What did work for me is, ahem, biting the bullet and just symlinking the system python install over to the homebrew. Feels dirty, but at least I get full omnicomplete working on third party modules now...
cd /System/Library/Frameworks/Python.framework/Versions
sudo mv Current Current-sys
sudo ln -s /usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7 Current
brew install macvim
sudo mv Current Current-brew
sudo mv Current-sys Current
Best Answer
After lots of digging, googling and trial and error, I've been able to get this all to work. I'm sharing my experiences here in the hope to save others the trouble.
The first step is to make sure that you have your Python properly installed. Check that
which python
gives back the right Python version (probably something like/usr/local/bin/python
)Properly linked boost
Check if your boost is linked against the right version of Python using the following command (Change /usr/local to your Homebrew prefix where necessary).
The result should contain the line:
If it points to somewhere in
/System/Library/Frameworks
, you need to rebuild your boost libraries and force a build from source (ref):Once that is done you can run the above line to verify it linked correctly.
Libtorrent-rasterbar with Python bindings
Now that boost is installed properly, libtorrent-rasterbar can use them to build the Python bindings. We have to edit the formula to enable them, but also to educate the build process on where to find them.
Execute
brew edit libtorrent-rasterbar
and then change it to match this:The two important lines here are to enable the python bindings with
--enable-python-binding
and the second is--with-boost-python=mt
to show that it has been installed with an "mt" suffix (ref).This will allow the build process to recognize the boost library which was installed in the first step. So close the editor, and do
brew install libtorrent-rasterbar
as normal.Final Check
Finally, to make sure that it all worked: