Chapter 6. Using Python in Red Hat Enterprise Linux 8

6.1. Introduction to Python

Python is a high-level programming language that supports multiple programming paradigms, such as object-oriented, imperative, functional, and procedural. Python has dynamic semantics and can be used for general-purpose programming.

With Red Hat Enterprise Linux, many packages that are installed on the system, such as packages providing system tools, tools for data analysis or web applications are written in Python. To be able to use these packages, you need to have the python packages installed.

6.1.1. Python versions

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

Red Hat Enterprise Linux 8 uses Python 3.6 by default. However, Python 2.7 is also provided to support existing software.


Neither the default python package nor the unversioned /usr/bin/python executable is distributed with Red Hat Enterprise Linux 8.


Always specify the major version of Python when installing it, invoking it, or otherwise interacting with it. For example, use python3, instead of python, in package and command names. All Python-related commands should also include the version, for example, pip3 or pip2.

Alternatively, configure the system default version by using the alternatives command as described in Configuring the unversioned Python.

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

  • Python 3 represents the main development direction of the Python project.
  • Support for Python 2 in the upstream community ends in 2020.
  • Popular Python libraries are dropping Python 2 support in upstream.
  • Python 2 in Red Hat Enterprise Linux 8 will have a shorter life cycle and its aim is to facilitate smoother transition to Python 3 for customers.

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

  • Python 3 allows writing expressive, maintainable, and correct code more easily.
  • Code written in Python 3 will have greater longevity.
  • Python 3 has new features, including asyncio, f-strings, advanced unpacking, keyword only arguments, chained exceptions and more.

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 6.2.3, “Configuring the unversioned Python”.

6.1.2. The internal platform-python package

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.

6.2. Installing and using Python


Using the unversioned python command to install or run Python does not work by default due to ambiguity. Always specify the major version of Python as described in Installing and using Python 3 and Installing and using Python 2, or configure the system default version by using the alternatives command as described in Section 6.2.3, “Configuring the unversioned Python”.

6.2.1. Installing and using Python 3

In Red Hat Enterprise Linux 8, Python 3 is distributed as the python36 module in the AppStream repository.

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

To install Python 3, use the following command as root:

yum install python3

This command installs Python 3.6 from the python36 module in AppStream. Using Python 3

To run Python 3, use the python3 command. Use the version in all other related commands, such as pip3. Naming conventions for Python 3 packages

Packages with add-on modules for Python 3 generally use the python3- prefix.

For example, to install the Requests module that is used for writing HTTP clients, run:

yum install python3-requests

6.2.2. Installing and using Python 2

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.


Note that Python 3 is the main development direction of the Python project. The support for Python 2 is being phased out. The python27 module has a shorter support period than Red Hat Enterprise Linux 8. Installing Python 2

To install Python 2, run as root:

yum install python2

This command installs Python 2.7 from the python27 module in AppStream. Using Python 2

To run Python 2, use the python2 command. Use the version in all other related commands, such as pip2. Naming conventions for Python 2 packages

Packages with add-on modules for Python 2 generally use the python2- prefix.

For example, to install the Requests module that is used for writing HTTP clients, run:

yum install python2-requests

6.2.3. Configuring the unversioned Python

System administrators can configure the unversioned python command on the system using the alternatives command. Note that the required package, either python3 or python2, needs to be installed before configuring the unversioned command to the respective version.

To configure the unversioned python command to Python 3 directly, run:

alternatives --set python /usr/bin/python3

Use an analogous command if you choose Python 2.

Alternatively, you can configure the unversioned python command interactively:

  1. Run the following command:

    alternatives --config python
  2. Select the required version from the provided list.

To reset this configuration and remove the unversioned python command, run:

alternatives --auto python

Additional Python-related commands, such as pip3, do not have configurable unversioned variants.

6.3. Migrating from Python 2 to Python 3

As a developer, you may want to migrate your former code that is written in Python 2 to Python 3. For more information on how to migrate large code bases to Python 3, see The Conservative Python 3 Porting Guide.

Note that after this migration, the original Python 2 code becomes interpretable by the Python 3 interpreter and stays interpretable for the Python 2 interpreter as well.

6.4. Packaging of Python 3 RPMs

Most Python projects use Setuptools for packaging, and define package information in the file. For more information on Setuptools packaging, see Setuptools documentation.

You can also package your Python project into an RPM package, which provides the following advantages compared to Setuptools packaging:

  • Specification of dependencies of a package on other RPMs (even non-Python)
  • Cryptographic signing

    With cryptographic signing, content of RPM packages can be verified, integrated, and tested with the rest of the operating system.

For more information on RPM packaging, see Packaging and distributing software.

6.4.1. Typical SPEC file description for a Python RPM package

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:

  • Preamble (contains a series of metadata items that are used in the Body)
  • Body (contains the main part of the instructions)

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 python3 prefix.

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

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


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

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

%py3_build                                                                      5


%{__python3} test                                                      6

%files -n python3-%{modname}
%license LICENSE

The modname macro contains the name of the Python project. In this example it is detox.
When packaging a Python project into RPM, the python3 prefix always needs to be added to the original name of the project. The original name here is detox and the name of the RPM is python3-detox.
BuildRequires specifies what packages are required to build and test this package. In BuildRequires, always include items providing tools necessary for building Python packages: python36-devel and python3-setuptools. The python36-rpm-macros package is required so that files with /usr/bin/python3 shebangs are automatically changed to /usr/bin/python3.6. For more information, see Section 6.4.4, “Handling hashbangs in Python scripts”.
Every Python package requires some other packages to work correctly. Such packages need to be specified in the SPEC file as well. To specify the dependencies, you can use the %python_enable_dependency_generator macro to automatically use dependencies defined in the file. If a package has dependencies that are not specified using Setuptools, specify them within additional Requires directives.
The %py3_build and %py3_install macros run the build and install commands, respectively, with additional arguments to specify installation locations, the interpreter to use, and other details.
The check section provides a macro that runs the correct version of Python. The %{__python3} macro contains a path for the Python 3 interpreter, for example /usr/bin/python3. We recommend to always use the macro rather than a literal path.

6.4.2. Common macros for Python 3 RPM packages

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.

MacroNormal DefinitionDescription



Python 3 interpreter



The full version of the Python 3 interpreter.



Where pure-Python modules are installed.



Where modules containing architecture-specific extensions are installed.



Runs the build command with arguments suitable for a system package.



Runs the install command with arguments suitable for a system package.

6.4.3. Automatic provides for Python RPM packages

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

  • .dist-info
  • .egg-info
  • .egg-link

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.

6.4.4. Handling hashbangs in Python scripts

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. The BRP script will generate errors when encountering a Python script with an ambiguous hashbang, such as:

#! /usr/bin/python


#! /usr/bin/env python

To modify hashbangs in the Python scripts causing these build errors at RPM build time, use the script from the platform-python-devel package: -pn -i %{__python3} PATH …​

Multiple PATHs can be specified. If a PATH is a directory, recursively scans for any Python scripts matching the pattern ^[a-zA-Z0-9_]+\.py$, not only those with an ambiguous hashbang. Add this command to the %prep section or at the end of the %install section.

Alternatively, modify the packaged Python scripts so that they conform to the expected format. For this purpose, can be used outside the RPM build process, too. When running outside a RPM build, replace __python3 from the example above with a path for the hashbang, such as /usr/bin/python3.

If the packaged Python scripts require Python version 2, replace the number 3 with 2 in the commands above.

Additionally, hashbangs in the form /usr/bin/python3 are by default replaced with hashbangs pointing to Python from the platform-python package used for system tools with Red Hat Enterprise Linux.

To change the /usr/bin/python3 hashbangs in their custom packages to point to a version of Python installed from Application Stream, in the form /usr/bin/python3.6, add the python36-rpm-macros package into the BuildRequires section of the SPEC file:

BuildRequires:  python36-rpm-macros

To prevent hashbang check and modification by the BRP script, use the following RPM directive:

%undefine %brp_mangle_shebangs