How to Install Python for AI on Linux

By the end of this guide you will have a modern Python on your Linux machine, an isolated project folder where you can install AI packages freely, and a script that has already made one successful call to a model. Budget about twenty minutes, most of which is downloading. Nothing here touches or replaces the Python your operating system depends on.

That last point is the whole reason Linux deserves its own guide. On Windows and macOS, Python is something you add. On Linux it is already there, wired into system utilities, your package manager and sometimes your desktop itself. Install AI libraries carelessly and you can break tools you did not know were written in Python. This guide is part of Setting Up Python for AI, which covers the same ground for every operating system, and it shows the safe path from a stock install to a working AI environment.

Prerequisites

You need surprisingly little to start:

• Any current Linux release — Ubuntu, Debian, Linux Mint, Pop!_OS, Fedora, or an enterprise rebuild such as Rocky or Alma. The commands below cover the two big families: the Debian family, which uses apt, and the Red Hat family, which uses dnf.
• A terminal and an account with sudo. The terminal is the text window where you type one command and press Enter. sudo means "run this one command as the administrator" and will ask for your login password. You will use it exactly twice in this guide, both times to install packages from your distribution's own repository.
• An internet connection, since both the packages and the AI libraries download at install time.
• (For Step 4 only) an API key — a secret string that lets your script call a hosted model. If you do not have one yet, Best Free AI APIs for Beginners lists no-cost options you can practise with.

Running Windows with WSL? The Windows Subsystem for Linux gives you a real Ubuntu shell, and every command on this page works inside it unchanged. Follow this guide if your editor, files and terminal all live on the Linux side. If instead you plan to run scripts from PowerShell or a Windows-native editor, use How to Install Python for AI on Windows so your paths and activation commands match the rest of your machine. Mixing the two is the single most common source of "it worked yesterday" confusion.

Step 1 — Find out what your distribution already ships

Never download a Python installer for Linux before checking what you have. Open a terminal and run these three commands:

cat /etc/os-release
python3 --version
which -a python3

The first prints your distribution name and version, which decides whether you use apt or dnf later. The second prints the interpreter version, something like Python 3.12.3. The third shows every python3 on your PATH — the list of folders your shell searches for commands — and on a fresh machine it should show a single line, /usr/bin/python3.

Read the version number carefully, because it decides which of three routes you take. Python 3.10 or newer is fine: current AI libraries, including the openai SDK, dropped support for 3.9 after it reached end of life, so 3.10 is the practical floor. Anything older and you will add a newer interpreter alongside the old one in Step 5.

One naming quirk catches everyone: on most distributions the bare command python does not exist at all, only python3. That is deliberate, so that ancient scripts written for Python 2 cannot silently run on a Python 3 interpreter. Type python3 everywhere until you activate a virtual environment, after which plain python starts working again.

Step 2 — Install pip and venv from your package manager

Two small pieces are often missing from a stock install: pip, the tool that downloads Python libraries, and venv, the built-in module that creates isolated project folders. Install both from your distribution's own repository so they stay consistent with the interpreter they serve.

On Ubuntu, Debian, Mint and Pop!_OS:

sudo apt update
sudo apt install -y python3 python3-venv python3-pip

On Fedora, Rocky, Alma or RHEL:

sudo dnf install -y python3 python3-pip

Fedora's python3 package already contains the venv module, so there is no separate package to add there. Debian and Ubuntu split it out, which is why python3 -m venv fails on a fresh Ubuntu until you install python3-venv.

Now the rule that matters more than any command on this page: never run sudo pip install. It looks harmless and it is how half the tutorials on the internet are written, but it drops files into directories that apt or dnf maintain a database for. The package manager does not know those files exist. A later upgrade can overwrite them, or remove a dependency your hand-installed library still needs, and you end up with a system Python that is neither what the distribution shipped nor what you installed. On some desktops that means your settings app or your terminal itself stops opening.

Recent releases of both families enforce this for you. Try to install into the system Python and pip stops with:

error: externally-managed-environment

× This environment is externally managed

That is PEP 668, a Python standard that lets a distribution mark its interpreter as owned by the package manager. It is not a bug and it is not something to override with --break-system-packages, a flag whose name is an accurate description of what it does. It is a signpost telling you to create a virtual environment, which is what the next step does.

Step 3 — Create and activate a virtual environment

A virtual environment is a folder holding its own copy of the interpreter's launch scripts and its own library directory. Packages you install while it is active land in that folder and nowhere else. Make one per project:

mkdir -p ~/ai-projects/first-ai-script
cd ~/ai-projects/first-ai-script
python3 -m venv .venv
source .venv/bin/activate

Your prompt now starts with (.venv). That prefix is the only visual signal that the environment is active, and it disappears the moment you open a new terminal tab, which trips people up constantly. Confirm the switch really happened:

which python
python -c "import sys; print(sys.prefix)"

Both should point inside your project folder, not /usr/bin. Notice that plain python works now — activation puts .venv/bin at the front of your PATH, and that directory contains a python symlink even though the system does not. Type deactivate to leave the environment and your shell returns to normal.

The mechanism is worth ten seconds of attention, because understanding it makes every later import error obvious rather than mysterious. Activation does not install anything or change any global setting; it only reorders the folders your shell searches, and the interpreter it finds there decides which library directory imports resolve against.

If you want the longer treatment of environments, including how to share one with a colleague, read Create a Python Virtual Environment for AI.

Step 4 — Install the openai SDK and make a first call

With (.venv) showing in your prompt, install the libraries. No sudo — that would defeat the whole point:

python -m pip install --upgrade pip
python -m pip install "openai>=1.40" "httpx>=0.27" "python-dotenv>=1.0"
python -m pip freeze > requirements.txt

Using python -m pip rather than a bare pip is a small habit with a large payoff on Linux: it guarantees you are talking to the pip belonging to the interpreter you just activated, even if an older pip executable is still sitting somewhere on your PATH.

Store your key in a file named .env in the project folder:

OPENAI_API_KEY=sk-your-real-key-goes-here

Add .env to .gitignore before you write another line, so the key can never be committed:

echo ".env" >> .gitignore

A key pushed to a public repository gets scraped and spent by strangers within minutes. When you move beyond experiments, Manage API Keys Safely in Production covers the next level of protection.

Now create first_call.py:

import os

from dotenv import load_dotenv
from openai import OpenAI

load_dotenv()  # reads .env from the current folder; .env is in .gitignore

client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "user", "content": "In one sentence, what is a virtual environment?"}
    ],
)

print(response.choices[0].message.content)
print("Tokens used:", response.usage.total_tokens)

Run it with python first_call.py. A sentence of generated text and a token count mean your interpreter, your environment, your packages and your key are all working together. That is the entire setup finished.

Step 5 — When your distribution's Python is too old

Long-support releases sometimes ship a Python older than 3.10, and enterprise rebuilds can be older still. Do not upgrade or remove the system interpreter; install a second one alongside it.

On Ubuntu, the deadsnakes archive is the standard route. It is a community-maintained repository that packages additional Python versions for Ubuntu releases:

sudo apt install -y software-properties-common
sudo add-apt-repository -y ppa:deadsnakes/ppa
sudo apt update
sudo apt install -y python3.12 python3.12-venv
python3.12 --version

/usr/bin/python3 still points at the original version and every system script keeps working. You simply name the new interpreter explicitly when creating an environment:

cd ~/ai-projects/first-ai-script
rm -rf .venv
python3.12 -m venv .venv
source .venv/bin/activate
python --version

Inside the activated environment, plain python is now 3.12 regardless of what the rest of the machine uses. Two caveats: deadsnakes targets Ubuntu, not Debian, and adding any third-party repository means trusting whoever maintains it. On Fedora, no extra repository is needed — versioned packages such as sudo dnf install python3.12 are in the standard repositories. On Debian, the cleanest options are a backports package if one exists for your release, or a version manager such as pyenv that builds interpreters in your home folder.

Command reference by distribution family

The final row is identical everywhere, including inside WSL and on macOS. Only the package-installation line differs between distributions.

Troubleshooting

error: externally-managed-environment — you ran pip against the system interpreter on a PEP 668 distribution. The fix is not a flag; activate a virtual environment first with source .venv/bin/activate, then repeat the install.

The virtual environment was not created successfully because ensurepip is not available — Debian and Ubuntu ship venv in a separate package. Run sudo apt install python3-venv, delete the half-built folder with rm -rf .venv, and create it again.

bash: pip: command not found — either no environment is active, or your distribution never installed a bare pip executable. Check for the (.venv) prefix, activate if it is missing, and call python -m pip instead of pip.

ModuleNotFoundError: No module named 'openai' — you installed into one interpreter and ran the script with another, which usually means a new terminal tab where activation was lost. Run which python to see which interpreter you are on; the walkthrough in Fix ModuleNotFoundError: No Module Named openai covers the remaining causes, and Read a Python Traceback in Five Minutes helps you decode the next error yourself.

SSL: CERTIFICATE_VERIFY_FAILED — common on minimal server images and behind corporate proxies, where the root certificate bundle is missing or intercepted. Install ca-certificates from your package manager first, then see Fix SSL: CERTIFICATE_VERIFY_FAILED in Python.

When to use this vs. alternatives

• Package manager plus venv — what this guide teaches, and the right default for almost everyone. It uses tools already on your machine, needs no extra downloads, and matches how servers are configured, so a script that runs locally runs the same way when you deploy it.
• A version manager such as pyenv — worth adding when you juggle several projects pinned to different Python versions, or when you are on Debian where deadsnakes is not an option. It compiles interpreters into your home folder, which takes longer and needs build dependencies, but keeps root out of the picture entirely.
• Conda or a container — reach for these when your work involves heavy scientific packages with compiled dependencies, or when you need the exact same environment reproduced on someone else's machine. For calling hosted AI APIs, both add setup and disk footprint you will not use.

Your Linux machine is now a proper AI workstation: a system Python that is still exactly as your distribution shipped it, a project folder you can install anything into, and a script that has already talked to a model. The next thing worth doing is picking somewhere comfortable to write code — Choose a Code Editor for Python AI Work compares the options and shows how to point each one at the environment you just built. After that, repeat Step 3 for every new project. It costs ten seconds and saves entire afternoons.

Back to Setting Up Python for AI.

Related guides

• Create a Python Virtual Environment for AI — the deeper treatment of environments, requirements files and sharing a project.
• Choose a Code Editor for Python AI Work — pick an editor and connect it to the .venv you just created.
• How to Install Python for AI on Windows — the native Windows route if you are not staying inside WSL.
• How to Install Python for AI Projects on Mac — the equivalent Homebrew-based setup on macOS.
• Fix the 401 Unauthorized Error in OpenAI Python — what to check if your first call comes back rejected.