Okay, best for me, anyway. In some ways, setting up Python isn’t terribly hard. You can just download an installer from Python.org and be done with it. Or download Anaconda or another distribution like it. But there are a ton of reasons that might not work for you, and doesn’t for me.
- MacOS since version 10.8 comes with Python 2.7 pre-installed by Apple. If you wish, you are invited to install the most recent version of Python 3 from the Python website (A current “universal binary” build of Python, which runs natively on the Mac’s new Intel and legacy PPC CPU’s, is available there.
- This tutorial will guide you through installing Python 3 on your local macOS computer and setting up a programming environment on the command line with Terminal. Python is a versatile programming language that can be used for many different programmin.
To check that Python on Mac has updated properly, launch Terminal again and type: python3 -version. Note: When updating Python to version 3.x, don’t try to delete the old Python version 2.x from your Mac. That’s because your Mac utilities are actually made to use the old version, and deleting it could cause all sorts of critical errors to.
My Go-To Toolchain
Updated python, virtualenvwrapper, and VSCode. That’s the name of the game. For the last year and a half or so I’ve been mostly developing on Windows, but I’m back on a Mac and installing a development environment there for the first time in a while, and there are some oddities to work through there.
1 – Python
First you’ve got to get an up-to-date python 2.7, and possibly 3.x as well. MacOS always ships with an old python installed in /usr/bin – as of this writing, Mac OS 10.13.6 is the latest, with Python 2.7.10. My preferred way to do this is:
- Install homebrew: https://brew.sh/
brew install [email protected]
brew install python
This will get you a shiny new up-to-date python at /usr/local/bin, as well as a python3. If you want, you can just install python3 and point the /usr/local/bin/python symlink at that, but I think it’s probably not ideal – it might break other things on the system that expect
python to mean 2.7.
This is soft of where virtualenvs come in – make python behave just as you like, on a project-by-project basis
2 – virtualenvwrapper
Using python virtual environments gives a few advantages over using your system environment for everything. Most obviously, you can install only the packages your project needs, and keep track of what that list is. You can also get specific about the versions of those packages, or even of the python interpreter itself. This last bit is really useful – you don’t want to override
python3 at the system level, but maybe you want to develop a project with python 3.x and don’t want to manually remember to use python3 for everything.
Installing virtualenvwrapper is easy:
pip install virtualenvwrapper
Using it is mostly a matter of familiarizing yourself: http://virtualenvwrapper.readthedocs.io/en/latest/
But there’s a bit of a hitch here. It turns out, there are two kinds of Python on Mac – “framework builds” and not-that. The key differentiation here is that framework builds have access to GUI APIs, which is necessary for all softs of graphical things in Python. Most importantly for me, matplotlib doesn’t work outside of a framework build. Conveniently, homebrew installs framework builds by default now. Inconveniently, virtualenv doesn’t, whether or not the source binary is a framework build. So even if your system python is a framework build, the one inside my_env when you
mkvirtualenv my_env won’t be.
There’s all sorts of relevant info in this thread, but this comment in particular highlights a so-far very functional solution copied below: https://github.com/pypa/virtualenv/issues/54#issuecomment-177344059
Of course, this has to be done every time a new virtualenv gets made, so to make it automatic, here’s the ~/.virtualenvs/postmkvirtualenv I’m using:
With this little hack/workaround, your not-framework-build is magically framework-ized and all GUI-requiring packages in your virtualenv will work as expected. I’m unaware of any drawbacks yet, aside from the up-front hassle.
The last piece of this is VSCode. My typical workflow is to have the
code command available on my terminal (Shift-Cmd-P>Install code command, inside vscode). When I want to work on a project, I go there in terminal,
workon my_env, then
code .. That is:
This will launch VSCode with your virtualenv at the front of the $PATH, adopting the virtualenv’s interpreter and package list.
But there’s a bug at least as of time of writing – newly-created terminals and child processes in VSCode get created with the virtualenv at the END of the $PATH, for some reason that totally escapes me. Here’s the bug report: https://github.com/Microsoft/vscode-python/issues/2333#issuecomment-410426411
Install Numpy On Mac
Luckily, the workaround isn’t terrible – every time you launch code with a new virtualenv, instead of it just working, you have to make the extra step of Shift-Cmd-P>Python: Select interpreter, and pick the interpreter inside your virtualenv. And make sure you pick the one with Python.app in its path, so that you’re getting the framework build that works with GUI APIs.
Another possible workaround is to put the following in your
Install Python On Mac Anaconda
By adding that, you should just about completely obviate the need for setting your python interpreter deliberately in settings.json as we do above, and bonus, all child terminals in Code will have the proper environment activated so you’ll never accidentally
pip install something into the wrong environment!
Pylint for Python 3.7.0
One last note: the latest Pylint release doesn’t properly support Python 3.7.0 at this time. The workaround is to install the latest beta release with
pip install --pre -U pylint astroid. This will fix the
RuntimeError: generator raised StopIteration in Code when it automatically runs the linter and that fails. If you are in the habit of creating lots of virtualenvs and this is a big annoyance, you might add the line above into $WORKON_HOME/postmkvirtualenv as well, but be sure you set a reminder to remove it once the latest Pylint stable release supports 3.7.0 properly.
And that ought to do it!
Footnote: if you’re interested in my process for figuring out all the bugs with this setup, here’s an excel sheet of experiment data: