5

I know there are brew-gem and brew-pip but it is still really easy to get confused. Let's say my Mac OS X is 10.7.2.

  • There are at least, as far as I know, 3 locations for Python modules (assume 2.7):
    1. /System/Library/Frameworks/Python.framework/Versions/2.7/
    2. /Library/Python/2.7/site-packages
    3. /usr/local/lib/python2.7/site-packages/ (controlled within homebrew)
  • For some Python modules, pip install them into 2, the so-called local/customized Python module location, and everything looks and works great. Ex, readline by easy_install (ipython suggested me to install readline by easy_install instead of pip)
  • For some, it would try to install some miscellaneous files (ex, man, doc, ...) into system-wide location, which requires sudo! Ex, ipython insisted on installing man and doc into /System/Library/Frameworks/Python.framework/Versions/2.7/share/, which violates permission issue and all I can do is to use sudo.
  • For some Python modules installed by brew, they are symbolic linked to /usr/local/lib/python2.7/site-packages/. Everything seems great except that you have to remember to add this location into PYTHONPATH.

I am wondering any suggested and uniform way to handle those mass, or any explanation to make those stuff crystal clear.

1
  • I don't have a crystal clear solution, except perhaps use a few installation methods as possible.
    – dsummersl
    Commented Aug 10, 2012 at 12:40

2 Answers 2

3

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.:

  1. Notes on using pip and virtualenv with Django. (most of the post is not django-specific)
  2. 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.

4
  • You'll stick with it untill pip install scipy or PySide or PyQt4 fails, then we'll be back to figuring out how best to move brew-installed modules on Mac OSX Lion.
    – hobs
    Commented Oct 30, 2012 at 20:59
  • What you mean "move"? The whole idea is that you install your modules in your virtualenv and use no system-wide installation locations.
    – m000
    Commented Oct 31, 2012 at 11:05
  • FYI, just tried it and scipy installs like a charm inside virtualenv. There were a couple of minor issues (numpy not listed as a dep, me not having installed a fortran compiler) but nothing puzzling or hard to overcome. I'd bet that the other two modules won't have a problem either, provided you have installed the required native libraries and headers with brew. If you have some specific problem with your installation, please ask a new question with the details and don't just call BS on a solution that worked for this question and should work for the vast majority of cases.
    – m000
    Commented Oct 31, 2012 at 11:14
  • I love virtualenv and virtualenvwrapper, and use them on Mac OS X. But the only way I could get ipython with pyqt and scipy, etc installed was with brew. By 'move' I mean link to the appropriate global site-packages from the venv site-packages. That's what I ended up having to do to get ipython+pyqt+matplotlib+scipy all working within a virtualenv on my Lion Mac
    – hobs
    Commented Oct 31, 2012 at 17:51
0

My suggestions:

  1. Install the xcode commandline tools package via Xcode -> Preferences -> Downloads-> Components: xcode

  2. Install homebrew (upgrade your path in .profile, .SHELLrc or whatever to include /usr/local/bin before the system default like /usr/bin).

  3. For python first install all the prereqs by themselves:

    • brew install readline sqlite gdbm pkg-config
    • brew install python --framework --universal
    • update your path so that it uses the right distutils: export PATH=/usr/local/share/python:$PATH
  4. easy_install pip

  5. pip install virtualenv
  6. pip install virtualenvwrapper
  7. Include export PYTHONPATH=/usr/local/lib/python:$PYTHONPATH
3
  • Wow! You remove the builtin python stuff and make a symbolic to homebrew one?! Really risky.
    – Drake Guan
    Commented Aug 22, 2012 at 7:54
  • The builtin Python is awful anyway -- nothing in the OS depends on it. Commented Aug 22, 2012 at 16:38
  • Interesting approach - note that in step 4, easy_install is a single command, not two words.
    – RichVel
    Commented May 21, 2018 at 7:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .