Python on a mac

May 24, 2014 4:30 PM

What are your "best practices" for managing/using python on a mac?

I have had a macbook for half a year and I have been very satisfied with macports for all of my linux-y needs. I installed python-2.7 through macports and have been also installing all packages (e.g., numpy, matplotlib) through macports as well. Today, though, there was a package I needed (fcm) which was not available through macports; I learned about pip, found that package through pip and installed it. Unfortunately, neither pip ("pip freeze") nor macports ("port installed") knows about the python packages that the other has installed.

I made a rash decision and: uninstalled all macports packages, installed python27 and py27-pip through macports, and then proceeded to install all python packages through pip. This worked fine, until I tried to reinstall some (non-python) macports packages which depend on python (e.g., inkscape). Macports immediately recognized the dependency, tried to install, e.g., py27-numpy, and then failed because it "already exists and does not belong to a registered port." I guess I could give up on the macports python version altogether, use the native MacOS version along with the native pip, but then macports will still try to install its own version of python when it runs into a dependency (or can I somehow tell it to use the native python?).

Is there a best way to use python on a mac?

posted by pjenks to Computers & Internet (13 answers total)

Best answer: I write python on a Mac for a living. I think you need virtualenv, which creates an isolated python environment, with separated packages, for each project, and to manage the entire list of requirements for each virtualenv using pip's requirements.txt feature.

With a new machine I would:

* Install homebrew, not macports
* Install pip
* Install virtualenv, and virtualenvwrapper

Pip is used for installing (almost) all python packages, homebrew is for system libraries/macports-style stuff. I try to install everything into a virtualenv. I think the only exception is pip/virtualenv itself and some virtualenv-unfriendly packages like wx).

Then, for each python project:

* mkvirtualenv [project_name]
* workon [project_name]
* pip install -r requirements.txt

I also use autoenv, and put the 'workon' command in a .env file for each project, so it activates the virtualenv when I change to the folder.
posted by cogat at 4:43 PM on May 24, 2014 [13 favorites]

The very best thing you can do is use virtualenv. It does exactly what it sounds like: creates a virtual environment in which you can install whatever packages you want using pip. It makes having multiple different versions of Python on a single machine trivial and painless.

My personal workflow is to use Homebrew to install the Python interpreter, then install virtualenv (and virtualenvwrapper), then activate the new virtualenv and use pip to install everything else.

(On preview: I see coget has made basically the same recommendations. Proof that the Zen of Python - 'There should be one-- and preferably only one --obvious way to do it.' - is right!)
posted by asterix at 4:46 PM on May 24, 2014 [1 favorite]

I use the free version of Continuum Analytics' Anaconda Python distribution. Their package manager can install binary distributions of libraries like numpy, which can be nice for quickly setting up a working environment on a new machine without waiting for things to compile.
posted by Jotnbeo at 5:00 PM on May 24, 2014

Seconding homebrew instead of macports, and the liberal use of virtualenv.
posted by snap, crackle and pop at 5:08 PM on May 24, 2014

Response by poster: Thanks all for the converging advice on homebrew and virtualenv. I have a few related followups then, if y'all are available:

1) Why homebrew over macports? I can't recall why I made that choice six months ago, but I've been satisfied with macports. What is the difference/advantage?

2) I will often use python for various scripts which I want to use on the fly, i.e., things not associated with a particular "project". Is it necessary to be always working within a virtualenv? What is the default version when using virtualenv?

3) Does homebrew solve the problem that I had with macports? In order to install some other programs (e.g., inkscape), macports wants to install its own version of python (or python packages) to satisfy dependencies.
posted by pjenks at 5:20 PM on May 24, 2014

Virtualenv is likely overkill if you're not developing lots of software for deployment. It doesn't hurt, but it's also fine to use pip to manage your default monolithic environment, particularly given your use case.
posted by wrok at 5:30 PM on May 24, 2014

Best answer: Fourthing homebrew and virtualenv. Any other way is madness. I love each project having its own environment. Different versions of django, celery, numpy, scipy, etc. PIL vs pillow, etc. No need to worry "well, I have django 1.5 installed because of that project I took over last week, but now that I'm starting a new one, I want to start a new project, I want django 1.6. Though maybe I want to kick the tires on django 1.7 this weekend.

1) Why homebrew over macports? I can't recall why I made that choice six months ago, but I've been satisfied with macports. What is the difference/advantage?

I've found brew to be simpler/cleaner to deal with than macports. Macports has a much larger selection, but I haven't found myself wanting anything. (Chances are if I am, I'll go with @snickerdoodle's suggestion and use debian in virtualbox.

2) I will often use python for various scripts which I want to use on the fly, i.e., things not associated with a particular "project". Is it necessary to be always working within a virtualenv? What is the default version when using virtualenv?

No. You just won't have any packages. If you need django 1.6 for a project, say you're trying to create a blog, make a virtual environment called myblog, activate it (literally two commands that take less than 5 seconds to type and execute), install django 1.6. When your done, deactivate your virtenv. When you inherit a project later on that uses django 1.5, you create a virtenv for it, activate it and tell pip to install the contents of the requirements.txt file. No need to worry that you have django 1.6 installed.

3) Does homebrew solve the problem that I had with macports? In order to install some other programs (e.g., inkscape), macports wants to install its own version of python (or python packages) to satisfy dependencies.

brew's inkscape does not require or optionally recommend the brew python or python 3 packages, but I haven't used it.

AFAIK, whether you use brew's python or OS X's python is up to you and how you configure your $PATH, as long as both meet whatever other requirements your software has. (I use brew's python)
posted by Brian Puccio at 5:52 PM on May 24, 2014 [1 favorite]

Homebrew does make /usr/local/bin/ world-writeable, which is a bit of a security faux pas.
posted by scruss at 8:06 PM on May 24, 2014 [1 favorite]

Interesting to see the rapid convergence on advice. For me:

* I used to have Fink on my old machine; on this one I started with MacPorts and have been happy with it so far. But it appears that the cool kids have moved on to Homebrew...

* I used to have terrible Python package issues until I realized that I could get the full Enthought Python Distribution (EPD, now Canopy), and that had everything that I had been having trouble with. For the few stray packages I use pip and it plays well enough with EPD. (My $PATH gets the EPD python before the system one.)
posted by RedOrGreen at 9:03 PM on May 24, 2014 [1 favorite]

Virtualenv's and Python via MacPorts (preferred by me) or Homebrew.

Never ever use pip to install packages using sudo or you could hose your system's Python and your Mac.
posted by zaphod at 9:44 PM on May 24, 2014

Brew, always. Never MacPorts. Homebrew has never led me astray. MacPorts has caused more than a couple of "Welp, I guess this is so fucked I'm going to need a system reinstall" for me and others I know.

Someone will probably say that's my own fault somehow, and maybe it is, but whatever it is that I do that triggers that in Macports has never once caused a problem with Homebrew.

Virtualenv is a must-have, regardless of who supplies your python install.
posted by toomuchpete at 10:07 PM on May 24, 2014 [1 favorite]

I bet the entire Metafilter audience for this story is already reading this page:

Python 3 is killing Python; the Python community should fork Python 2.

Currently, on OS X 10.8.5,
$ /usr/bin/python --version
Python 2.7.2
$ python --version
Python 2.7.3 -- 64-bit (This is my Enthought Canopy version)
posted by RedOrGreen at 8:37 AM on May 26, 2014

Yup, read that as well as the response, Python 3 can revive Python via HN.
posted by Brian Puccio at 8:46 AM on May 27, 2014