Two incompatible versions of Python are widely used, Python 2.x and Python 3.x.

RHEL 8 provides the following versions of Python.

See Red Hat Enterprise Linux Life Cycle and Red Hat Enterprise Linux 8 Application Streams Life Cycle for details about the length of support.

Each of the Python versions is distributed in a separate module, and by design, you can install multiple modules in parallel on the same system.

The python38 module does not include the same bindings to system tools (RPM, DNF, SELinux, and others) that are provided for the python36 module.

As a system administrator, you are recommended to use preferably Python 3 for the following reasons:

For developers, Python 3 has the following advantages over Python 2:

However, existing software tends to require /usr/bin/python to be Python 2. For this reason, no default python package is distributed with Red Hat Enterprise Linux 8, and you can choose between using Python 2 and 3 as /usr/bin/python, as described in Section 9.2.5, “Configuring the unversioned Python”.

System tools in Red Hat Enterprise Linux 8 use a Python version 3.6 provided by the internal platform-python package. Red Hat advises customers to use the python36 package instead.

In Red Hat Enterprise Linux 8, Python 3 is distributed in versions 3.6 and 3.8, provided by the python36 and python38 modules in the AppStream repository.

For details regarding modules in RHEL 8, see Installing, managing, and removing user-space components.

Packages with add-on modules for Python 3.6 generally use the python3- prefix; packages for Python 3.8 include the python38- prefix. Always include the prefix when installing additional Python packages, as shown in the examples below.

Some software has not yet been fully ported to Python 3, and needs Python 2 to operate. Red Hat Enterprise Linux 8 allows parallel installation of Python 3 and Python 2. If you need the Python 2 functionality, install the python27 module, which is available in the AppStream repository.

For details regarding modules, see Installing, managing, and removing user-space components.

Packages with add-on modules for Python 2 generally use the python2- prefix. Always include the prefix when installing additional Python packages, as shown in the examples below.

When running the Python interpreter or Python-related commands, always specify the version.

When running the Python 2 interpreter or Python2-related commands, always specify the version.

System administrators can configure the unversioned python command, located at /usr/bin/python, using the alternatives command. Note that the required package, python3, python38, or python2, needs to be installed before configuring the unversioned command to the respective version.

A SPEC file contains instructions that the rpmbuild utility uses to build an RPM. The instructions are included in a series of sections. A SPEC file has two main parts in which the sections are defined:

For further information about SPEC files, see Packaging and distributing software.

An RPM SPEC file for Python projects has some specifics compared to non-Python RPM SPEC files. Most notably, a name of any RPM package of a Python library must always include the prefix determining the version, for example, python3 for Python 3.6 or python38 for Python 3.8.

Other specifics are shown in the following SPEC file example for the python3-detox package. For description of such specifics, see the notes below the example.

%global modname detox                                                           1

Name:           python3-detox                                                   2
Version:        0.12
Release:        4%{?dist}
Summary:        Distributing activities of the tox tool
License:        MIT
URL:            https://pypi.io/project/detox
Source0:        https://pypi.io/packages/source/d/%{modname}/%{modname}-%{version}.tar.gz

BuildArch:      noarch

BuildRequires:  python36-devel                                                  3
BuildRequires:  python3-setuptools
BuildRequires:  python36-rpm-macros
BuildRequires:  python3-six
BuildRequires:  python3-tox
BuildRequires:  python3-py
BuildRequires:  python3-eventlet

%?python_enable_dependency_generator                                            4

%description

Detox is the distributed version of the tox python testing tool. It makes efficient use of multiple CPUs by running all possible activities in parallel.
Detox has the same options and configuration that tox has, so after installation you can run it in the same way and with the same options that you use for tox.

    $ detox

%prep
%autosetup -n %{modname}-%{version}

%build
%py3_build                                                                      5

%install
%py3_install

%check
%{__python3} setup.py test                                                      6

%files -n python3-%{modname}
%doc CHANGELOG
%license LICENSE
%{_bindir}/detox
%{python3_sitelib}/%{modname}/
%{python3_sitelib}/%{modname}-%{version}*

%changelog
...

In a SPEC file, always use the macros below rather than hardcoding their values.

In macro names, always use python3 or python2 instead of unversioned python. Configure the particular Python 3 version in the BuildRequires of the SPEC file to either python36-rpm-macros or python38-rpm-macros.

When packaging a Python project, make sure that, if present, the following directories are included in the resulting RPM:

From these directories, the RPM build process automatically generates virtual pythonX.Ydist provides, for example, python3.6dist(detox). These virtual provides are used by packages that are specified by the %python_enable_dependency_generator macro.

In Red Hat Enterprise Linux 8, executable Python scripts are expected to use hashbangs (shebangs) specifying explicitly at least the major Python version.

The /usr/lib/rpm/redhat/brp-mangle-shebangs buildroot policy (BRP) script is run automatically when building any RPM package, and attempts to correct hashbangs in all executable files.

#! /usr/bin/python

#! /usr/bin/env python

%undefine %brp_mangle_shebangs