LiveChat 
Support 
How to Install Python on Ubuntu (Without Breaking Your System)
Most guides that tell you to install Python on Ubuntu are quietly dangerous. They hand you a `sudo pip install` command, or worse, they walk you through replacing `/usr/bin/python3` — and then act surprised when `apt` stops working. Ubuntu does not treat Python as an optional tool you bolt on. Python 3 is a load-bearing part of the operating system itself, and the way you add Python matters as much as which version you choose.
This guide takes the careful path. We will confirm what Ubuntu already ships, add the missing pieces (`pip`, `venv`), install a specific newer Python version when you genuinely need one, and — most importantly — do all of it without touching the system interpreter your OS depends on.
Key Takeaways
• Ubuntu already has Python 3. Check with `python3 –version` before installing anything.
• There is no `python` command by default on modern Ubuntu. Use `python3`, or install `python-is-python3` if a script demands the `python` alias.
• Install pip and venv explicitly: `sudo apt install python3-pip python3-venv`.
• For a specific newer version, use the deadsnakes PPA (system-wide) or pyenv (per-project). Never compile over the system Python.
• Never run `sudo pip install` or alter the system interpreter. Modern Ubuntu blocks it on purpose (PEP 668). Use a virtual environment for every project.
Does Ubuntu Come With Python Already Installed?
Yes. Every supported Ubuntu release ships with Python 3 preinstalled, because core system utilities — parts of `apt`, `ubuntu-advantage-tools`, `netplan`, and many others — are written in Python and import the system interpreter directly. Before you install anything, verify what you have:
“`bash python3 –version
“`
That number is your system Python. Note it, and then mentally label it “do not touch.” It belongs to the OS.
The most common point of confusion: typing `python` returns `command not found`.
“`bash python –version
“`
This is intentional, not a bug. Modern Ubuntu does not provide an unversioned `python` command, to avoid the historical Python 2 versus Python 3 ambiguity. You have two correct responses:
- Just use `python3` everywhere. This is the right habit.
- If a third-party script hard-codes `python`, install the alias package:
“`bash sudo apt install python-is-python3 “`
This makes `python` point to `python3` via a managed symlink — safe, reversible, and packaged. Do not create that symlink by hand in `/usr/bin`; let `apt` own it.
How Do You Install pip and venv on Ubuntu?
Ubuntu ships the interpreter but deliberately keeps pip and the venv module in separate packages to keep the base image small. You almost always want both:
“`bash sudo apt update sudo apt install python3-pip python3-venv “`
Verify each:
“`bash pip3 –version python3 -m venv –help “`
A subtle footgun lives here. Installing `python3-pip` gives you a *system* pip. The instinct to then run `sudo pip install requests` is exactly the mistake this guide exists to prevent. We will get to why that breaks things — and what to do instead — shortly. For now, internalize this: system pip exists to support the OS, not your projects.
How Do You Install a Specific Python Version on Ubuntu?
Ubuntu’s repositories pin one Python 3 minor version per release. If you need a newer one — say `python3.12` on an older LTS, or `python3.13` for testing — you have three sane options. The table below is the decision you should actually make before typing any command.
| Method | Best for | Scope | Touches system Python? | Trade-off |
|---|---|---|---|---|
| apt (default repos) | The version your release ships | System-wide | It *is* the system Python | No version choice |
| deadsnakes PPA | A specific newer version, system-wide | System-wide, side-by-side | No (installs alongside) | Adds a third-party PPA |
| pyenv | Per-project / many versions | Per-user, no root | No | Compiles from source; build deps needed |
| Source build | Exotic/patched builds | Wherever you `–prefix` | No (if done right) | Manual; you maintain it |
Option A: The deadsnakes PPA (specific version, system-wide)
The deadsnakes Personal Package Archive is the community-standard way to get additional, packaged Python versions on Ubuntu. They install alongside the system interpreter as `python3.12`, `python3.13`, and so on — they do not replace `python3`.
“`bash sudo apt update sudo apt install software-properties-common sudo add-apt-repository ppa:deadsnakes/ppa sudo apt update sudo apt install python3.12 python3.12-venv “`
Then call it by its exact name so there is never ambiguity about which interpreter runs:
“`bash python3.12 –version python3.12 -m venv .venv “`
Failure mode to expect: if you forget the matching `python3.12-venv` package, `python3.12 -m venv .venv` fails with `ensurepip is not available`. Install the version-specific `-venv` package and retry. Never “fix” this by pointing the command at the system venv module.
Option B: pyenv (per-project version management)
When different projects need different Python versions, pyenv is the correct tool. It installs interpreters into your home directory, builds them from source, and shims the right one per directory — all without root and without going anywhere near the OS interpreter.
First install the build dependencies (this is the step people skip, then file confusing bug reports):
“`bash sudo apt update sudo apt install build-essential libssl-dev zlib1g-dev libbz2-dev \ libreadline-dev libsqlite3-dev curl libncursesw5-dev xz-utils \ tk-dev libxml2-dev libxmlsec1-dev libffi-dev liblzma-dev “`
Then install pyenv and a version:
“`bash curl https://pyenv.run | bash
exec “$SHELL” pyenv install 3.12.4 pyenv local 3.12.4 # writes .python-version for this project “`
Never run `sudo pip install`, and never modify or remove the system Python on Ubuntu. This is the single most important rule in this article. The OS depends on its system interpreter: `apt`, `apt_pkg`, unattended-upgrades, and a long list of utilities import it directly. A system-wide pip install can replace a library your OS expected at a specific version; deleting or relinking `/usr/bin/python3` can leave `apt` itself unable to start — meaning you can no longer install the very tools you would use to repair the system. Recovery from that state usually means a chroot or a reinstall. Modern Ubuntu now refuses system-wide pip installs by default, raising an `externally-managed-environment` error, precisely to stop people from doing this to themselves. Treat that error as the OS protecting you, not obstructing you. The correct answer is always the same: create a virtual environment for your project’s packages.
Why Does pip Say “externally-managed-environment”?
If you try the old habit on a current release:
“`bash pip3 install requests
“`
This is PEP 668 working as designed. Ubuntu marks its system Python as managed by `apt`, so pip declines to write into it. You will see suggestions to bypass it with `–break-system-packages`. The flag name is an honest warning — do not use it on the system interpreter for ordinary project work. It exists for narrow packaging scenarios, not for installing your app’s dependencies.
The right answer takes three commands.
How Do You Use a Virtual Environment (the Correct Way)?
A virtual environment is an isolated, self-contained Python directory that holds its own interpreter link and its own packages. Nothing you install in it can affect the OS, and you can delete the whole thing by removing one folder. This is how Python projects are *supposed* to be run.
“`bash
python3 -m venv .venv source .venv/bin/activate
pip install requests # no sudo, no PEP 668 error — this pip is local “`
When you are done, leave it with `deactivate`. The `.venv` folder is disposable; add it to `.gitignore` and recreate it from `requirements.txt` anywhere.
Here is the command vocabulary worth memorizing:
| Task | Command |
|---|---|
| Check system version | `python3 –version` |
| Create a venv | `python3 -m venv .venv` |
| Create with a specific version | `python3.12 -m venv .venv` |
| Activate | `source .venv/bin/activate` |
| Install a package (inside venv) | `pip install |
| Freeze dependencies | `pip freeze > requirements.txt` |
| Recreate elsewhere | `pip install -r requirements.txt` |
| Deactivate | `deactivate` |
Inside an active venv, plain `python` and `pip` refer to the venv’s copies — no `python3`/`pip3` distinction needed, and no `sudo` ever.
How Do You Verify the Install Worked?
Confidence comes from checking, not assuming. After setting things up:
“`bash
python3 –version
python3.12 –version
python3 -m venv /tmp/checkenv source /tmp/checkenv/bin/activate which python # should point inside /tmp/checkenv pip –version # should reference the venv path deactivate rm -rf /tmp/checkenv “`
If `which python` points inside your venv path and not `/usr/bin`, isolation is working correctly. That is the signal you want.
If you are doing this on a server — for a web app, a scheduled job, or an API — the same rules apply, but the stakes are higher because a broken system Python on a remote box is harder to rescue. DarazHost VPS and dedicated servers give you full root access to do this properly: add the deadsnakes PPA or run pyenv, install exactly the Python version your application targets, and run each project inside its own virtual environment on a clean, isolated machine. You get a predictable Python environment instead of fighting a shared host’s constraints, backed by reliable hosting and 24/7 support. It is the right foundation for Python projects that need to stay up.
Frequently Asked Questions
Should I install Python 2 on Ubuntu? Almost never. Python 2 is end-of-life and unsupported. Only install it for a specific legacy dependency you cannot migrate, and even then, isolate it. New code should target Python 3 exclusively.
Can I just use `sudo pip install` if I add `–break-system-packages`? You *can*, and you will eventually regret it. That flag overrides the PEP 668 protection that keeps your OS stable. For project dependencies, always use a virtual environment instead. Reserve `–break-system-packages` for rare, deliberate packaging tasks where you fully understand the consequences.
What is the difference between deadsnakes and pyenv? deadsnakes installs packaged Python versions system-wide via `apt`, alongside the system interpreter. pyenv installs versions per-user in your home directory by compiling them, and switches between them per project. Use deadsnakes for a shared, packaged version; use pyenv when projects need different versions.
Will installing python3.12 from deadsnakes replace my system Python? No. deadsnakes installs side-by-side. Your `python3` (and therefore `apt`) keeps pointing at the original system version. You invoke the new one explicitly as `python3.12`.
Why is there no `python` command on Ubuntu? By design, to avoid Python 2 versus Python 3 ambiguity. Use `python3`, or install `python-is-python3` to get a managed `python` alias safely.
