# Should I use Homebrew to install Python?

Homebrew ships Python because dozens of its own packages depend on it. Tools like `glib`, `cmake`, and `awscli` all pull in Python as a build or runtime dependency. When Homebrew installs Python, it is satisfying *its own* dependency graph, not setting up a development environment for you.

This distinction matters because Homebrew treats Python the same way it treats any other dependency: as something to keep current. Running `brew upgrade` can bump Python from 3.12 to 3.13 without warning, removing the previous minor version's `site-packages` directory in the process.

Any packages installed with `pip` into that Homebrew-managed Python vanish. Virtual environments linked against the old interpreter break with errors like `dyld: Library not loaded` or `No such file or directory: python3.12`.

## How Homebrew manages Python versions

Homebrew maintains a single "current" Python formula (`python@3.x`) plus versioned formulae for older releases that active packages still need. When the core formula advances, Homebrew rebuilds every dependent formula against the new version and removes the old one on cleanup. Developers who happened to be using that Python for their own projects lose their setup as a side effect of routine maintenance.

Homebrew also does not support installing patch-level versions. You can install `python@3.12`, but you cannot pin to Python 3.12.4 specifically, which rules it out for reproducible builds or matching a production interpreter.

## The `pip install` trap

Because `brew install python` puts a `python3` binary on your `PATH`, many developers start using it to install packages globally with `pip install`. This creates a fragile setup for two reasons:

1. Global `pip install` puts packages into Homebrew's `site-packages` directory, which Homebrew may wipe on upgrade.
2. If Homebrew's Python version advances, scripts with `#!/usr/bin/env python3` shebangs point to a different interpreter. That new interpreter lacks the previously installed packages.

Using a [virtual environment](https://pydevtools.com/handbook/explanation/what-is-a-virtual-environment.md) avoids the second problem, but environments created against a Homebrew Python still break when Homebrew removes that Python version.

## What to use instead

[uv](https://pydevtools.com/handbook/reference/uv.md) can [install and manage Python versions](https://pydevtools.com/handbook/how-to/how-to-install-python-with-uv.md) independently of Homebrew. It downloads pre-built interpreters in seconds, supports pinning exact versions (including patch releases), and works across macOS, Linux, and Windows. Because uv manages its own Python installations, a `brew upgrade` will never interfere with your development environment.

For projects that need a specific Python version, a [.python-version file](https://pydevtools.com/handbook/explanation/what-is-a-python-version-file.md) lets uv (and other tools like [pyenv](https://pydevtools.com/handbook/reference/pyenv.md)) automatically select the right interpreter per project.

> [!TIP]
> If Homebrew has already installed Python on your system, you do not need to remove it. Homebrew's Python will continue serving Homebrew's own packages. Just avoid using it for your development work.

## Learn More

* [How to install Python with uv](https://pydevtools.com/handbook/how-to/how-to-install-python-with-uv.md)
* [How to switch from pyenv to uv for managing Python versions](https://pydevtools.com/handbook/how-to/how-to-switch-from-pyenv-to-uv-for-managing-python-versions.md)
* [How do pyenv and uv compare for Python interpreter management?](https://pydevtools.com/handbook/explanation/how-do-pyenv-and-uv-compare-for-python-interpreter-management.md)
* [Homebrew](https://pydevtools.com/handbook/reference/homebrew.md) reference page covers what Homebrew is and what it is best used for.