Cannot “sudo pip uninstall” operation not permitte

Preface: My OS X Python installation is a mess. I started using the system Python way before I found out about Homebrew. And so I've been using sudo pip install since forever. I'm now trying to clean everything up and then install/link pip packages against Homebrew's Python.

1) In many SO answers, people suggest doing: pip freeze | xargs sudo pip uninstall -y That doesn't work for me. I get a very long traceback. These are the most representative chunks of it:

~ $ pip freeze | xargs sudo pip uninstall -y
You are using pip version 7.1.2, however version 8.0.2 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
The directory '/Users/smaniato/Library/Caches/pip/http' or its parent directory is not owned by the current user and the cache has been disabled. Please check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.
Uninstalling altgraph-0.10.2:
Exception:
Traceback (most recent call last):
  File "/Library/Python/2.7/site-packages/pip/basecommand.py", line 211, in main
[...]
Error: [('/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/altgraph/__init__.py', '/tmp/pip-p8yIlU-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/altgraph/__init__.py', "[Errno 1] Operation not permitted: '/tmp/pip-p8yIlU-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/altgraph/__init__.py'"), ('/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/altgraph/__init__.pyc', '/tmp/pip-p8yIlU-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/altgraph/__init__.pyc',
[...]
"[Errno 1] Operation not permitted: '/tmp/pip-p8yIlU-uninstall/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/altgraph'")]

where altgraph is just the first pip package in pip list (keep that in mind).

2) I then tried pip freeze | xargs sudo -H pip uninstall -y, as the warning suggested, but that simply remove the warning. The error messages persisted.

3) I also tried chown-ing any directories that raised complaints (e.g., ~/Library/Caches/pip and some of its parents and children). For some reason, I cannot chown the most problematic directory, /tmp:

~ $ sudo chown -R ${USER} /tmp
chown: /tmp: Operation not permitted

4) Finally, I tried manually uninstalling a package from further down the list and voila, I could easily do sudo pip uninstall virtualenv for example. Attempting to manually uninstall altgraph results in the same error above.

Any ideas how to proceed? Remember, I don't care about any one package; I just want to nuke pip and start from scratch using Homebrew's Python. Thanks!

Updates:

Going down the list manually, the same thing happens with bdist-mpkg-0.5.0
A few more: matplotlib, zope.interface, xattr, six, scipy, pytz.

回答1:

I'm pretty sure that brew reinstall python somehow fixed a bunch of the issues I was having. I then had to also nuke (i.e., rm -rf) a few things in /usr/local/lib/python2.7/site-packages

Issue and answer related to my specific use case (ROS installation on OS X): https://github.com/mikepurvis/ros-install-osx/issues/11

回答2:

Don't use Homebrew nor MacPorts, nor the builtin Python. These are nested solutions that will eventually fail, one way or another (PEP20: flat is better than nested). At the very least, you will have to wait for the package management system to notice any PyPI updates, or fall back to using pip as you would have done anyway without any package manager. Use MacPorts to install only non-Python items that need to compile and be customized (e.g., ATLAS).

The simplest thing to do is to install a stand-alone Python from python.org (either from a binary distribution, or build from source). No sudo, install under your user. Then:

pip install -U pip setuptools virtualenvwrapper

Source your wrapper from your ~/.bashrc per their docs, and makevirtualenv foo. All other work will be performed in virtual environments only. If you use Python 3, then virtualenv is part of the interpreter, so you don't need virtualenvwrapper and the little dance related to it.