Why should I avoid using the system Python?
The “system Python” is the Python interpreter that ships with your operating system. On macOS and most Linux distributions, it lives at /usr/bin/python3. Windows doesn’t ship Python by default, but a system-wide install from python.org or the Microsoft Store fills the same role and runs into most of the same problems.
This interpreter exists for the operating system, not for development work. Using it for your own projects causes three categories of problems.
It can break your OS
macOS and Linux rely on the system Python to run internal tools. Package managers, system utilities, and desktop components import modules from the system site-packages directory. Installing, upgrading, or removing packages in that directory can silently break those tools. On Ubuntu, for example, overwriting the system requests library can break apt itself. Windows doesn’t have this specific risk (nothing in the OS depends on Python), but the other two problems still apply to any Python you share across projects.
Modern distributions have started fighting back. PEP 668 introduced the EXTERNALLY-MANAGED marker, which causes pip install to refuse to modify system site-packages by default. If you have ever seen the externally-managed-environment error, that marker is the reason.
It forces you into a single version
The system Python ships one version, chosen by the OS vendor for compatibility, not currency. macOS 15 still ships Python 3.9. Ubuntu’s LTS releases typically lag current Python by one to two versions (24.04 ships Python 3.12). If a project needs a different version, the system interpreter cannot help.
Multiple projects on the same machine often need different Python versions. Without a way to switch interpreters, developers end up compiling Python from source or installing from third-party PPAs, both of which create maintenance headaches.
It lacks isolation
Every pip install into the system Python adds packages to a single, shared directory. Two projects that depend on different versions of the same library cannot coexist. The last install wins, and the other project breaks silently.
What to do instead
Use uv to manage both Python versions and virtual environments. For a project, a single command installs any Python version and creates an isolated environment:
$ uv init my-project
$ cd my-project
$ uv add requests
uv downloads the right Python interpreter automatically, creates a virtual environment, and records dependencies in pyproject.toml. Each project gets its own environment, its own interpreter, and its own set of packages.
For scratch scripts and one-offs, you don’t need a project at all. uv run --with requests script.py builds a throwaway environment for a single command, and PEP 723 inline metadata lets a script declare its own dependencies. See do I need a project to use uv? for the full menu of no-project options.
Tip
Even a manually installed Python (from python.org or Homebrew) shares the same isolation problem. Always use virtual environments regardless of how Python was installed.
Related
- What is a virtual environment? explains what virtual environments are and how they work
- Why should I use a virtual environment? covers the benefits of isolation in more detail
- Do I need a project to use uv? describes the no-project patterns for scratch scripts and CLI tools
- How to install Python with uv shows how to get any Python version without touching the system interpreter
- Should I use Homebrew to install Python? discusses another common installation method and its trade-offs
- How do pyenv and uv compare for Python interpreter management? compares two tools for managing Python versions