Prerequisites for installing Python3 on Mac
$ brew install python3 Error: python 2.7.13 is already installed To upgrade to 3.6.43, run `brew upgrade python` This comment has been minimized. Sign in to view. Homebrew tap for Python versions. Contribute to sashkab/homebrew-python development by creating an account on GitHub. If you had installed several versions of python3, you may find more than one python3.x icons, each one corresponds to a single python3 version instance, you may choose which one to remove. If you installed python3 via a package manager like brew, you need to use the remove command from the package manager, for example, brew uninstall python3.
Install Xcode
Xcode is Apple's Integrated Development Environment (IDE). You might already have Xcode on your Mac. If not, you can get Xcode from Apple appstore.
Install Brew
Homebrew installs the stuff you need. Homebrew is a package manager for Mac OS
Step 1. Launch Terminal.
Go to Launchpad – Other – Terminal
Step 2. Install HomeBrew
Install Python3 with Brew
Enter brew command into terminal
brew install python3
Optional, PATH environment
Set up PATH environment variable, if you used HomeBrew to install Python3, then HomeBrew already added PATH.
Do not change PATH environment if you can launch python3 from terminal.
Add the following line to your ~/.profile file
export PATH=/usr/local/bin:/usr/local/sbin:$PATH
Usually your Python installation directory looks like this, add it to your PATH
PATH='/Library/Frameworks/Python.framework/Versions/3.6/bin:${PATH}'
Brew Python3 Manual
This document explains how to successfully use Python in a Homebrew formula.
Homebrew draws a distinction between Python applications and Python libraries. The difference is that users generally do not care that applications are written in Python; it is unusual that a user would expect to be able to import foo after installing an application. Examples of applications are ansible and jrnl.
Python libraries exist to be imported by other Python modules; they are often dependencies of Python applications. They are usually no more than incidentally useful in a terminal. Examples of libraries are py2cairo and the bindings that are installed by protobuf.
Bindings are a special case of libraries that allow Python code to interact with a library or application implemented in another language.
Homebrew is happy to accept applications that are built in Python, whether the apps are available from PyPI or not. Homebrew generally won’t accept libraries that can be installed correctly with pip install foo. Bindings may be installed for packages that provide them, especially if equivalent functionality isn’t available through pip.
Applications should unconditionally bundle all of their Python-language dependencies and libraries and should install any unsatisfied dependencies; these strategies are discussed in depth in the following sections.
Applications
Python declarations
Formulae for apps that require Python 3 should declare an unconditional dependency on 'python@3.x'. These apps must work with the current Homebrew Python 3.x formula.
Applications that are compatible with Python 2 should use the Apple-provided system Python in /usr/bin on systems that provide Python 2.7. No explicit Python dependency is needed since /usr/bin is always in PATH for Homebrew formulae.
Installing
Applications should be installed into a Python virtualenv environment rooted in libexec. This prevents the app’s Python modules from contaminating the system site-packages and vice versa.
All of the Python module dependencies of the application (and their dependencies, recursively) should be declared as resources in the formula and installed into the virtualenv, as well. Each dependency should be explicitly specified; please do not rely on setup.py or pip to perform automatic dependency resolution, for the reasons described here.
You can use brew update-python-resources to help you write resource stanzas. To use it, simply run brew update-python-resources <formula>. Sometimes, brew update-python-resources won’t be able to automatically update the resources. If this happens, try running brew update-python-resources --print-only <formula> to print the resource stanzas instead of applying the changes directly to the file. You can then copy and paste resources as needed.
If using brew update-python-resources doesn’t work, you can use homebrew-pypi-poet to help you write resource stanzas. To use it, set up a virtualenv and install your package and all its dependencies. Then, pip install homebrew-pypi-poet into the same virtualenv. Running poet some_package will generate the necessary resource stanzas. You can do this like:
Homebrew provides helper methods for instantiating and populating virtualenvs. You can use them by putting include Language::Python::Virtualenv at the top of the Formula class definition.
For most applications, all you will need to write is:
This is exactly the same as writing:
Example
Installing a formula with dependencies will look like this:
You can also use the more verbose form and request that specific resources be installed:
in case you need to do different things for different resources.
Bindings
To add bindings for Python 3, please add depends_on 'python@3.x' to work with the current Homebrew Python 3.x formula.
Build Python 2 bindings with the system Python by default (don’t add an option) and they should be usable with any binary-compatible Python. If that isn’t the case, it’s an upstream bug; here’s some advice for resolving it.
Dependencies
Bindings should follow the same advice for Python module dependencies as libraries; see below for more.
Installing bindings
If the bindings are installed by invoking a setup.py, do something like:
If the configure script takes a --with-python flag, it usually will not need extra help finding Python.
If the configure and make scripts do not want to install into the Cellar, sometimes you can:
- call
./configure --without-python(or a similar named option) cdinto the directory containing the Python bindings- call
setup.pywithsystemandLanguage::Python.setup_install_args(as described above)
Sometimes we have to edit a Makefile on-the-fly to use our prefix for the Python bindings using Homebrew’s inreplace helper method.
Libraries
Python declarations
Libraries built for Python 3 should include depends_on 'python@3.x', which will bottle against Homebrew’s Python 3.x. Python 2.x libraries must function when they are installed against either the system Python or brewed Python.
Python 2 libraries need a uses_from_macos 'python@2' declaration; they will be built with the system Python, but should still be usable with any other Python 2.7. If this is not the case, it’s an upstream bug; here’s some advice for resolving it.
Installing
Libraries may be installed to libexec and added to sys.path by writing a .pth file (named like “homebrew-foo.pth”) to the prefix site-packages. This simplifies the ensuing drama if pip is accidentally used to upgrade a Homebrew-installed package and prevents the accumulation of stale .pyc files in Homebrew’s site-packages.
Most formulae presently just install to prefix.
Dependencies
The dependencies of libraries must be installed so that they are importable. To minimise the potential for linking conflicts, dependencies should be installed to libexec/<vendor> and added to sys.path by writing a second .pth file (named like “homebrew-foo-dependencies.pth”) to the prefix site-packages.
Further down the rabbit hole
Additional commentary that explains why Homebrew does some of the things it does.
setuptools vs. distutils vs. pip
Distutils is a module in the Python standard library that provides developers a basic package management API. Setuptools is a module distributed outside the standard library that extends distutils. It is a convention that Python packages provide a setup.py that calls the setup() function from either distutils or setuptools.
Setuptools provides the easy_install command, which is an end-user package management tool that fetches and installs packages from PyPI, the Python Package Index. pip is another, newer end-user package management tool, which is also provided outside the standard library. While pip supplants easy_install, pip does not replace the other functionality of the setuptools module.
Distutils and pip use a “flat” installation hierarchy that installs modules as individual files under site-packages while easy_install installs zipped eggs to site-packages instead.
Distribute (not to be confused with distutils) is an obsolete fork of setuptools. Distlib is a package maintained outside the standard library which is used by pip for some low-level packaging operations and is not relevant to most setup.py users.
Running setup.py
In the event that a formula needs to interact with setup.py instead of calling pip, Homebrew provides a helper method, Language::Python.setup_install_args, which returns useful arguments for invoking setup.py. Your formula should use this instead of invoking setup.py explicitly. The syntax is:
where prefix is the destination prefix (usually libexec or prefix).
What is --single-version-externally-managed?
--single-version-externally-managed (“SVEM”) is a setuptools-only argument to setup.py install. The primary effect of SVEM is to use distutils to perform the install instead of using setuptools’ easy_install.
easy_install does a few things that we need to avoid:
- fetches and installs dependencies
- upgrades dependencies in
sys.pathin-place - writes
.pthandsite.pyfiles which aren’t useful for us and cause link conflicts
Setuptools requires that SVEM is used in conjunction with --record, which provides a list of files that can later be used to uninstall the package. We don’t need or want this because Homebrew can manage uninstallation but since setuptools demands it we comply. The Homebrew convention is to call the record file “installed.txt”.
Detecting whether a setup.py uses setup() from setuptools or distutils is difficult, but we always need to pass this flag to setuptools-based scripts. pip faces the same problem that we do and forces setup() to use the setuptools version by loading a shim around setup.py that imports setuptools before doing anything else. Since setuptools monkey-patches distutils and replaces its setup function, this provides a single, consistent interface. We have borrowed this code and use it in Language::Python.setup_install_args.
--prefix vs --root
setup.py accepts a slightly bewildering array of installation options. The correct switch for Homebrew is --prefix, which automatically sets the --install-foo family of options using sane POSIX-y values.
--rootis used when installing into a prefix that will not become part of the final installation location of the files, like when building a .rpm or binary distribution. When using a setup.py-based setuptools, --root has the side effect of activating --single-version-externally-managed. It is not safe to use --root with an empty --prefix because the root is removed from paths when byte-compiling modules.
It is probably safe to use --prefix with --root=/, which should work with either setuptools or distutils-based setup.py’s but is kinda ugly.
Brew Install Python 3
pip vs. setup.py
Homebrew Python 3.9
PEP 453 makes a recommendation to downstream distributors (us) that sdist tarballs should be installed with pip instead of by invoking setup.py directly. We do not do this because Apple’s Python distribution does not include pip, so we can’t assume that pip is available. We could do something clever to work around Apple’s piplessness but the value proposition is not yet clear.