Fedora 45 reached general availability on November 3, 2026, after two delays from the original October 20 target. It ships Python 3.15 as the system interpreter, up from 3.14. The first thing most people try is python --version, and that is where the confusion starts. The command may not exist. It may point to something you did not expect. Or it may work, and you then run pip install and get an “externally managed environment” error that looks like a bug but is deliberate.

Managing Fedora servers and workstations for years teaches one lesson. Python on Fedora is not something you “install” in the Windows sense. It is already the backbone of dnf-adjacent tooling, Anaconda-derived installers, cloud-init, and a long list of system utilities. Treat it carelessly and a routine pip install --upgrade can break a package manager helper at 2 AM.

This guide covers the practical path. You will verify what is already installed, add the development packages you actually need, install older or newer interpreters side by side, build isolated environments, and avoid the traps that cause most support tickets. The commands work on Fedora 45 and are noted where RHEL-family systems (AlmaLinux, Rocky) or Debian and Ubuntu behave differently. If you maintain mixed fleets, those notes will save you time.

What Fedora 45 Ships for Python

Fedora moves fast on Python. The Python 3.15 change was approved by FESCo, and every Python-dependent package had to be rebuilt against it. Packages that failed to rebuild were retired at Final Freeze unless they got an exception. That is why Fedora feels current, and why a rarely maintained third-party RPM occasionally disappears between releases.

Fedora 45 also carries a few changes that affect Python users directly. The release notes say python-setuptools moved to version 82, which is not fully compatible with earlier releases, so code that imports pkg_resources should migrate to importlib.resources and importlib.metadata. Pandas is now 3.x, and python-dateutil is deprecated in Fedora 45. OpenSSL is now 4.0, which matters if you compile C extensions against it.

Older interpreters remain available as separate packages. Fedora 45 still receives security updates for python3.12, for example, with version 3.12.15 fixing eight vulnerabilities including SSL context issues. That means you can pin legacy projects without leaving the distribution’s update stream.

Why the system Python matters

Several core Fedora tools run on the system interpreter. Replacing it, symlinking over it, or installing packages into its site-packages with pip as root can break them. The golden rule: leave /usr/bin/python3 alone, and build everything else around it.

Check What Is Already Installed

Start with facts instead of assumptions.

cat /etc/fedora-release
python3 --version
which python3
rpm -q python3

On a clean Fedora 45 Workstation you should see Python 3.15.x. Minimal and container images may omit it. Check pip and venv support too:

python3 -m pip --version
python3 -m venv --help | head -n 3

If pip is missing, that is normal on some installs. Fedora splits pip into its own package.

The python command

Fedora does not guarantee a bare python command unless you install the alias package:

sudo dnf install python-unversioned-command

This provides /usr/bin/python pointing to python3. Scripts with #!/usr/bin/python shebangs then run. Do not skip over why this exists: many distributions made the unversioned name ambiguous for years after Python 2 retired, so Fedora keeps it opt-in. On production servers, prefer explicit python3 in scripts and service units.

Install Python on Fedora 45 with DNF

DNF is the right first choice. Packages are signed, patched by Fedora, and updated with the rest of the system. Fedora uses DNF5, and RPM 6.1 in this release adds enhanced package signature checking.

sudo dnf upgrade --refresh
sudo dnf install python3 python3-pip

Add the pieces most developers need:

sudo dnf install python3-devel python3-wheel python3-virtualenv gcc make

Here is why each matters. python3-devel provides headers (Python.h) required to compile C extensions such as psycopg2, lxml, or mysqlclient. gcc and make are the compilers those builds invoke. Without them, pip prints a wall of red text ending in “command ‘gcc’ failed”.

A shortcut is the group install:

sudo dnf group install development-tools

On DNF5 the group command syntax is dnf group install, and the older groupinstall form may still work as an alias. If one form fails, try the other.

Verify the installation

python3 --version
python3 -c "import ssl, sqlite3, zlib; print(ssl.OPENSSL_VERSION)"

Importing ssl, sqlite3, and zlib is a quick sanity check. If any fail, a dependent library is missing.

Install a Specific or Older Python Version

Real projects rarely match the system default. A client’s Django 4.2 app might need 3.11 or 3.12, while the OS moved on. Fedora packages multiple interpreters under versioned names.

dnf search python3. | grep -E '^python3\.[0-9]+\.'
sudo dnf install python3.12 python3.12-devel

Run it explicitly:

python3.12 --version
python3.12 -m venv ~/venvs/legacy-app

The versioned binary never touches /usr/bin/python3, so system tools stay safe. Availability changes by release. Python 3.12 is currently in the Fedora 45 repositories, with recent security fixes. Check with dnf list --available 'python3.*' before planning a project around a version.

Testing your code against the next release

Fedora’s own Python team asked users to test scripts against new interpreters early, using the versioned package even before it became default. This is a good habit. Install the next version alongside your stable one and run your test suite on both. You find deprecations while they are still warnings.

When Fedora does not have the version you need

Sometimes you need a version Fedora has dropped, such as Python 3.9 for an abandoned dependency. You have three clean options:

• Use uv to download a standalone build (see below).
• Run the workload in a container with a matching base image.
• Compile from source into /opt using altinstall.

Pick the container route for production. It isolates the legacy runtime and keeps the host current.

Use uv, pipx, and pyenv Where They Fit

uv for fast, isolated interpreters

uv has become a common daily driver among administrators for installing interpreters and environments quickly.

sudo dnf install uv

If the package is unavailable in your repositories, use pipx instead (below). Then:

uv python install 3.13
uv venv --python 3.13 .venv
source .venv/bin/activate
uv pip install requests

The advantage is speed and zero interference with RPM-managed Python. The trade-off is that downloaded interpreters are not patched by Fedora’s security team. You own the updates.

pipx for command-line tools

Installing a CLI tool such as ansible-lint, httpie, or black globally with pip is how systems get messy. pipx gives each tool its own virtual environment.

sudo dnf install pipx
pipx ensurepath
pipx install httpie

Log out and in again so the PATH change applies. Upgrade everything later with pipx upgrade-all.

pyenv, with caveats

pyenv compiles versions from source, which is flexible but slow, and it needs build dependencies:

sudo dnf install make gcc patch zlib-devel bzip2 bzip2-devel readline-devel \
  sqlite sqlite-devel openssl-devel tk-devel libffi-devel xz-devel

Be aware that Fedora 45 moves to OpenSSL 4.0. Older Python source releases may not build against it. If a pyenv build fails at the _ssl module, that is the usual cause. Prefer uv or Fedora’s own versioned packages for old versions.

Virtual Environments: The Right Way to Work

Never install project dependencies into the system interpreter. Create an environment per project.

mkdir -p ~/projects/demo && cd ~/projects/demo
python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
pip install requests flask
pip freeze > requirements.txt
deactivate

Why this matters in practice

Picture two applications on one server. One needs urllib3<2, the other needs urllib3>=2. In a shared site-packages, one of them breaks the moment you install the other. Separate environments make that conflict impossible. Rebuilding is also trivial: delete .venv, recreate, reinstall from the lock file.

Reproducible installs

Pin versions and use hashes for production deployments:

pip install --require-hashes -r requirements.txt

With hashes enforced, a tampered or swapped package fails the install. For larger projects, tools like pip-tools or uv pip compile generate hashed lockfiles.

Understanding the “Externally Managed Environment” Error

Run sudo pip install something on Fedora and you may see a message that the environment is externally managed. Fedora and other distributions follow PEP 668, which marks the system Python as managed by the package manager. The point is to stop pip and dnf from overwriting each other’s files.

Do not reach for --break-system-packages as a reflex. It exists as an escape hatch, not a workflow. Choose one of these instead:

1. Look for an RPM first: dnf search python3-requests.
2. Use a virtual environment for project libraries.
3. Use pipx for standalone tools.

If you need a Python library that Fedora packages, installing the RPM keeps it patched with the rest of your system. That alone justifies checking DNF first, particularly on servers where you want one update command to cover everything.

Compile Python from Source (When Truly Necessary)

Most admins can go years without it. When you must, use altinstall so you never replace the system binary.

sudo dnf install gcc make openssl-devel bzip2-devel libffi-devel zlib-devel \
  readline-devel sqlite-devel xz-devel tk-devel gdbm-devel ncurses-devel
cd /usr/local/src
sudo curl -O https://www.python.org/ftp/python/3.13.1/Python-3.13.1.tgz
sudo tar xzf Python-3.13.1.tgz
cd Python-3.13.1
sudo ./configure --enable-optimizations --with-lto --prefix=/opt/python3.13
sudo make -j"$(nproc)"
sudo make altinstall

Substitute whichever release you actually need and verify its checksum or signature from python.org before building. --enable-optimizations runs profile-guided optimization, which commonly produces a measurably faster interpreter at the price of a much longer build. -j"$(nproc)" uses all cores, but on a small VPS with limited RAM, reduce the job count or the build may be killed by the OOM killer.

You own security patches for anything built this way. Put a reminder in your calendar.

Troubleshooting Common Errors

python: command not found

Install python-unversioned-command, or call python3 explicitly.

error: externally-managed-environment

Expected behavior. Use a venv, pipx, or the RPM version.

No module named pip

sudo dnf install python3-pip

Or run python3 -m ensurepip --upgrade inside a venv.

Python.h: No such file or directory

You lack headers. Install python3-devel, or the versioned form such as python3.12-devel for a non-default interpreter.

gcc: command not found during pip install

sudo dnf install gcc gcc-c++ make redhat-rpm-config

redhat-rpm-config supplies compiler flags that many builds expect on Fedora.

ModuleNotFoundError: No module named ‘pkg_resources’

This one is likely on Fedora 45. Setuptools 82 is not fully compatible with earlier releases, and pkg_resources usage has to be replaced with importlib.resources and importlib.metadata. Short-term, pin an older setuptools inside the project’s venv (pip install "setuptools<81"), then migrate the code properly.

Wheels fail to build for Python 3.15

New interpreters often lack prebuilt wheels for a while, so pip falls back to compiling from source. If the build fails, check the project’s issue tracker for 3.15 support. Meanwhile, use python3.13 or python3.12 in a venv for that project.

SSL certificate errors

Check system certificates and time sync:

sudo dnf reinstall ca-certificates
timedatectl

A wrong system clock produces confusing certificate failures. Fix the clock first.

Broken tools after messing with system Python

If dnf helpers misbehave after someone ran pip as root, list stray packages with pip list --path /usr/lib/python3.15/site-packages and compare with rpm -qa 'python3-*'. Remove pip-installed duplicates and reinstall the RPMs with sudo dnf reinstall python3-<name>.