If you’ve landed here wondering how to install Python on Linux without breaking something, you’re already ahead of where I was years ago. The good news: Python plays beautifully with Linux. The catch: there’s a right way and a “why is my server on fire” way. I’ve done both, so let me save you the second one.
In this guide I’ll walk you through three solid methods, explain the dreaded externally-managed-environment error, and show you the virtual environment habit that keeps your system clean. If you want a wider view of package management first, my overview on how to install software on Linux is a good companion read.
Quick answer: On Ubuntu or Debian, run sudo apt update && sudo apt install python3 python3-pip python3-venv. On RHEL, Rocky, or AlmaLinux, run sudo dnf install python3 python3-pip. Then always create a virtual environment with python3 -m venv .venv before installing packages. That’s the whole game.
What You’re Actually Installing (And Why It Matters)
Before you type a single command, it helps to know what already lives on your machine. Nearly every Linux distribution ships with Python baked in. Tools like your package manager and parts of the desktop rely on it. That copy is not yours to mess with.
Get a VPS from as low as $11/year! WOW!
System Python vs Your Python
There are really two Pythons in your life on Linux. There’s system Python, owned by the operating system, and there’s the Python you install and develop against. Keeping these separate is the single most important idea in this whole article.
Here’s my cautionary tale. Early in my sysadmin days I ran sudo pip install on a production Debian box to “quickly” upgrade a package. It clobbered a dependency that apt itself needed. Suddenly the package manager wouldn’t run, and neither would half the cron jobs. I spent a long night and a lot of coffee rebuilding that machine. Lesson learned: never let your projects touch system Python.
“It is always recommended to use a virtual environment while developing Python applications. The system Python is owned by your operating system, and changing its packages can lead to unpredictable breakage.” — Python Packaging Authority
Which Python Version Should You Use in 2026?
Python 3.14 is the latest stable release this year, but newest isn’t always smartest. For real work, Python 3.12 and 3.13 are the safe targets. They’re widely deployed, and almost every library you’ll reach for supports them.
Python’s momentum is hard to overstate right now. It overtook JavaScript as the most-used language on GitHub in 2025, and its TIOBE Index share crossed 26% in 2026, the largest single-language share the index has ever recorded. Nearly three-quarters of the developers in the JetBrains Python Developers Survey use it professionally. You’re learning a tool that isn’t going anywhere.
We’ll cover three approaches in order of simplicity: the package manager, the deadsnakes PPA for specific versions, and pyenv for juggling many versions at once.
Method 1: Install Python via Package Manager (Quickest Way)
For most people, this is the answer. Your distro’s package manager installs a tested Python build in one command. This is the fastest route to python3 on Linux, and it’s where I’d start unless you have a specific reason not to.
Ubuntu and Debian (apt)
Open a terminal and run these two commands. The first refreshes your package list, the second installs Python along with pip and the venv module:
sudo apt update
sudo apt install python3 python3-pip python3-venvI always install python3-venv at the same time. On Debian and Ubuntu the venv module is split into its own package, and forgetting it leads to a confusing error later when you try to create an environment. Grab it now and save yourself the head-scratch.
Ubuntu 24.04 LTS ships Python 3.12 as its default, which is a great version to build on. To confirm everything landed:
python3 --version
pip3 --versionRHEL, Rocky Linux, and AlmaLinux (dnf)
On the Red Hat family, the package manager is dnf and the command is just as short:
sudo dnf install python3 python3-pipRHEL 9 ships Python 3.11, while Fedora 43 is already on 3.14. One extra tip from experience: if you plan to install packages with C extensions like numpy or cryptography, add the development headers too:
sudo dnf install python3-develWithout python3-devel, those packages fail to compile with cryptic gcc errors. I’ve watched more than one teammate burn an afternoon on that exact wall, so install it upfront if compiled libraries are in your future.
Method 2: Install a Specific Python Version on Ubuntu (deadsnakes PPA)
Sometimes the version your distro ships isn’t the one you need. Maybe you’re on an older Ubuntu LTS that defaults to Python 3.10, but your project requires 3.12. The deadsnakes PPA is the clean, canonical way to get newer versions without the overhead of a full version manager.
Add the repository, refresh, then install your target version:
sudo add-apt-repository ppa:deadsnakes/ppa
sudo apt update
sudo apt install python3.12 python3.12-venv python3.12-devThe key thing to understand: this does not change your system default. You run the new version explicitly by calling python3.12. Your system’s python3 stays exactly where it was, which is precisely what you want. No surprises, no broken OS tools.
When to use deadsnakes: You need one or two specific newer versions on Ubuntu, and you don’t want to manage a fleet of them. If you need to switch between many versions constantly, jump to pyenv in the next section instead.
Method 3: Manage Multiple Python Versions with pyenv
This is my daily driver. When you work across projects that each pin a different Python version, pyenv is a quiet hero. It lets you install as many versions as you like and switch between them per project, per shell, or system-wide for your user.
“pyenv lets you easily switch between multiple versions of Python. It’s simple, unobtrusive, and follows the UNIX tradition of single-purpose tools that do one thing well.” — pyenv project README
The magic is in how it works. pyenv prepends a directory of shim scripts to your PATH. Every time you call python, pip, or python3, the call routes through a shim first, which points to whichever version you’ve selected. It never touches your system binaries.
Install pyenv Build Dependencies
pyenv compiles Python from source, so it needs build tools present first. On Ubuntu and Debian, install these:
sudo apt install build-essential libssl-dev zlib1g-dev \
libbz2-dev libreadline-dev libsqlite3-dev libffi-dev curlSkip these and your Python builds will succeed but quietly lack features. The classic symptom is importing ssl or sqlite3 later and getting a module-not-found error. Installing the dev libraries first avoids that whole category of pain.
Install pyenv via Git
pyenv installs by cloning its Git repository, so you’ll want Git working first. If you’re new to it, my guide on how to use Git on Linux covers the basics. The official installer handles the clone for you:
curl https://pyenv.run | bashAfter it runs, you add three lines to your shell config so pyenv loads in every session. This means editing .bashrc and setting an environment variable. If that’s unfamiliar territory, see how to set environment variables in Linux and my walkthrough on how to write Bash scripts in Linux for what’s happening under the hood:
export PYENV_ROOT="$HOME/.pyenv"
[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init -)"Restart your terminal or run source ~/.bashrc to load the changes.
Install Python Versions and Switch Between Them
Now the fun part. Install a version, then set it as your default:
pyenv install 3.12.10
pyenv global 3.12.10pyenv gives you three scopes for choosing a version, and understanding them is what makes the tool click:
- global: Your user-wide default. Set with
pyenv global 3.12.10. - local: A per-directory version. Run
pyenv local 3.11.9inside a project and it writes a.python-versionfile. Anyone whocds into that folder gets 3.11.9 automatically. - shell: Just for your current terminal session. Set with
pyenv shell 3.13.2and it vanishes when you close the window.
That .python-version file is the part most tutorials skip. Commit it to your repo and every teammate’s pyenv picks the right version the moment they enter the directory. It’s one of those small touches that quietly prevents “works on my machine” arguments.
Always Use Virtual Environments — The Rule PEP 668 Enforces
No matter which method you chose above, this section is the one that actually keeps you out of trouble. A virtual environment is an isolated folder with its own Python and its own packages. Your projects stop fighting over dependencies, and your system Python stays pristine.
Why Modern Ubuntu Blocks Global pip Installs (PEP 668 Explained)
If you’re on Debian 12, Ubuntu 23.04, or anything newer, you’ve probably already hit this wall. You run pip install something and pip flatly refuses with an externally-managed-environment error. That’s not a bug. That’s PEP 668 doing its job.
The Python and distro maintainers added this guardrail precisely to stop the mistake I made on that Debian server years ago. The system Python is marked as externally managed, and pip respects that boundary. It’s protecting your OS from you.
Do not reach for --break-system-packages. Yes, that flag exists and yes, it silences the error. It also reintroduces the exact risk PEP 668 was built to prevent. I’ve never seen it end well on a machine that matters. Use a virtual environment instead. Every single time.
Create and Activate a venv in Three Commands
Here’s the whole workflow. The Python’s official virtual environments documentation and the PyPA guide on pip and virtual environments both back this exact pattern:
python3 -m venv .venv
source .venv/bin/activate
pip install requestsOnce activated, your prompt shows (.venv) and pip installs happily with no PEP 668 complaints, because you’re no longer touching system Python. When you’re done, type deactivate to step back out. Everything your project needs lives in that .venv folder, which you can delete and rebuild anytime.
One bonus worth knowing in 2026: uv, the Rust-based tool from Astral, does this same job 10 to 100 times faster than pip. It’s still optional, but it’s spreading fast, and it’s worth a look once the basics feel comfortable.
Troubleshooting Common Python Installation Problems
Even a clean install throws the occasional curveball. Here are the three issues I get asked about most, with the fixes that actually work.
error: externally-managed-environment
This is the PEP 668 message from above. The correct solution is a virtual environment, full stop. Create one with python3 -m venv .venv, activate it with source .venv/bin/activate, and install your packages there. Resist the urge to bypass the warning with a flag.
python: command not found
On most modern Linux systems the binary is named python3, not python. So python --version fails while python3 --version works fine. If a script insists on calling python, the cleanest fix is a shell alias. I keep alias python=python3 in my config, and you can learn the pattern in my guide on how to create Bash aliases.
pip: command not found or pip installs to wrong location
If pip itself is missing, install it with sudo apt install python3-pip on Debian-based systems, or bootstrap it with python3 -m ensurepip --upgrade. If pip runs but packages land in the wrong place, run which pip3 and confirm it points inside your active venv rather than at the system path. Nine times out of ten, the fix is simply activating your virtual environment first.
Quick Reference: Python Commands You’ll Use Every Day
Bookmark this table. These are the commands I type so often my fingers know them in the dark.
| Task | Command |
|---|---|
| Check Python version | python3 --version |
| Check pip version | python3 -m pip --version |
| Create a virtual environment | python3 -m venv .venv |
| Activate it | source .venv/bin/activate |
| Install a package | pip install package |
| Save dependencies | pip freeze > requirements.txt |
| List pyenv versions | pyenv versions |
| Install a pyenv version | pyenv install 3.12.10 |
| Set version scope | pyenv global / local / shell |
Where to Go From Here
You’ve got Python installed the clean way, you understand why PEP 668 exists, and you’ve got the virtual environment habit that separates tidy systems from broken ones. That’s a genuinely solid foundation.
From here, a few natural next steps. If you’re building full-stack apps, you’ll likely also need to install Node.js on Linux to pair with your Python backend. Want even stronger isolation than venv offers? Learning to use Docker on Linux takes environment separation to the next level. And since Ansible is written in Python and depends on a working install, this guide is also your launchpad for learning to use Ansible on Linux.
Once your scripts are running, you’ll probably want them running on a schedule. Pair Python with scheduled tasks with cron jobs, or for something more modern, learn to automate scripts with systemd timers. Both are great ways to put your fresh Python install to real work.
Browse the rest of our Linux guides when you’re ready, and happy building. The terminal’s waiting.
