How to Update Python Without Breaking the Version Your System Depends On

There is no single update Python command, because the right way depends on how Python got onto your machine. On Windows, download the new installer from python.org. On macOS, use Homebrew or the official installer. On Linux, do not touch the system Python your OS depends on - use pyenv or a virtual environment instead. The most important rule across all of them: installing a new Python does not delete the old one, and on Linux, deleting the system Python can brick parts of your operating system.

The reason this question has no clean answer is that Python is not one thing on your computer. There is the version your OS ships and relies on, versions you installed for your own work, and versions living inside virtual environments. Update the wrong one and you either accomplish nothing or break your system.

Table of contents

• First, find out what you have
• Windows: run the new installer
• macOS: Homebrew or the installer, not the system one
• Linux: never touch the system Python
• Virtual environments update the interpreter, not your packages
• How this fits the rest of the stack
• FAQ

First, find out what you have

Before updating anything, see what is installed and where:

python3 --version        # the version
which python3            # where it lives  (Windows: where python)
python3 -c "import sys; print(sys.executable)"

The path tells you a lot. /usr/bin/python3 is the system Python - handled by your OS package manager, and not something to update by hand. /usr/local/bin, a Homebrew path, or a pyenv shims path means a version you installed and can freely update.

Knowing which Python your python3 points at is the whole game. Updating a version that is not the one your projects use accomplishes nothing; updating the system one can break your OS. Two minutes of looking first saves an afternoon of confusion later.

Windows: run the new installer

On Windows, Python versions are independent installs. To update:

1. Download the latest installer from python.org.
2. Run it. For a new minor version (3.11 to 3.12), it installs alongside the old one. For a patch within the same minor (3.12.1 to 3.12.4), it upgrades in place.
3. Tick Add Python to PATH if you want the new one on your command line.

Minor versions (3.11, 3.12, 3.13) live side by side deliberately, because a project pinned to 3.11 should not be dragged to 3.12 without you deciding to. Use the py launcher to pick between them:

py -3.12 script.py
py -0        # list installed versions

The py launcher is the clean Windows answer to multiple versions - it ships with Python and lets you run any installed version without messing with PATH order.

macOS: Homebrew or the installer, not the system one

macOS ships its own Python that the OS uses. Leave it alone. Install and update your own.

With Homebrew, the common choice:

brew update
brew upgrade python

Or download the official python.org macOS installer, which installs into /Library/Frameworks separately from Apple’s copy and adds itself to your PATH.

Do not try to upgrade or remove the system Python in /usr/bin. macOS components may depend on it, and Apple intentionally makes it hard to change for that reason. Your work should use a Homebrew or python.org Python, or a pyenv-managed one - never the system framework. If python3 resolves to /usr/bin/python3, that is the signal you have not yet installed your own and should.

Linux: never touch the system Python

This is where people cause real damage. On most Linux distributions, core system tools are written in Python and depend on the exact version in /usr/bin/python3. Removing it or force-upgrading it can break your package manager and leave the system unbootable-adjacent.

So do not upgrade the system Python. Instead, install newer versions in parallel with pyenv, which keeps them entirely separate from the OS copy:

curl https://pyenv.run | bash        # install pyenv
pyenv install 3.12.4                  # build a new version
pyenv global 3.12.4                   # make it your default
pyenv local 3.11.9                    # or pin one per project

pyenv builds each version under your home directory and switches between them with shims, never touching /usr/bin. Your OS keeps its Python; you get whatever version you want for your own work. This is the safe, standard way to run a modern Python on a distro that ships an older one.

Virtual environments update the interpreter, not your packages

One more source of confusion: updating Python does not update the Python inside your existing virtual environments. A venv is tied to the interpreter that created it.

python3.12 -m venv .venv     # new venv on the new version
source .venv/bin/activate
pip install -r requirements.txt

After you install a new Python, recreate your project’s venv against it and reinstall dependencies. The old venv keeps pointing at the old interpreter until you rebuild it - which is often what you want, so a version bump is a deliberate, per-project decision rather than a global one.

This is also why updating Python rarely breaks anything if you use venvs: each project pins its own interpreter, so a new system-wide version does not disturb projects that have not opted in. Virtual environments turn the scary global update into a series of small, safe, per-project moves.

How this fits the rest of the stack

Version management is really about keeping one project’s Python from stepping on another’s - the same isolation a managed runtime gives you when each service declares the version it needs and gets exactly that. Pinning a Python version per project locally is the habit that makes the deployed version predictable too. The RunxBuild hosting calculator lays out the service, database, storage, and bandwidth as separate line items, and the RunxBuild dashboard is where the team watches deploys, logs, and restarts as they happen.

Useful related references:

• Update Node Version Without Breaking Your Deploy
• ModuleNotFoundError: No Module Named pip — Fix It Without Breaking Python
• Change Python Version: The Three Tools That Make It Stop Hurting
• Python services on RunxBuild

FAQ

How do I update Python?

It depends on how you installed it. On Windows, run the latest installer from python.org. On macOS, use brew upgrade python or the official installer. On Linux, do not touch the system Python - use pyenv to install newer versions in parallel. Check which python3 first to see what you have.

Will updating Python delete my old version?

Not for minor versions. Installing 3.12 alongside 3.11 leaves 3.11 in place; only a patch update within the same minor version upgrades in place. This is deliberate, so projects pinned to an older version keep working until you migrate them.

Why should I not update the system Python on Linux?

Because core OS tools, including the package manager, are written in Python and depend on the exact version in /usr/bin/python3. Removing or force-upgrading it can break your system. Install newer versions with pyenv, which keeps them separate from the OS copy.

What is pyenv and why use it?

pyenv installs and switches between multiple Python versions under your home directory without touching the system Python. It lets you set a global default and pin a specific version per project, which is the safe way to run a modern Python on a distro that ships an older one.

Do I need to recreate my virtual environments after updating Python?

Yes, if you want them on the new version. A virtual environment is tied to the interpreter that created it and does not follow a Python upgrade. Recreate it with python3.12 -m venv .venv and reinstall your dependencies to move a project to the new version.