Installing and using dynamic programming languages
Installing and using Python and PHP in Red Hat Enterprise Linux 9
Abstract
Providing feedback on Red Hat documentation Copy linkLink copied to clipboard!
We are committed to providing high-quality documentation and value your feedback. To help us improve, you can submit suggestions or report errors through the Red Hat Jira tracking system.
Procedure
Log in to the Jira website.
If you do not have an account, select the option to create one.
- Click Create in the top navigation bar.
- Enter a descriptive title in the Summary field.
- Enter your suggestion for improvement in the Description field. Include links to the relevant parts of the documentation.
- Click Create at the bottom of the dialogue.
Chapter 1. Introduction to Python Copy linkLink copied to clipboard!
Python is a high-level programming language that supports multiple programming paradigms, such as object-oriented, imperative, functional, and procedural paradigms. 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 use these packages, you must have the python* packages installed.
1.1. Python versions Copy linkLink copied to clipboard!
Python 3.9 is the default Python implementation in RHEL 9. Python 3.9 is distributed in a non-modular python3 RPM package in the BaseOS repository and is usually installed by default. Python 3.9 will be supported for the whole life cycle of RHEL 9.
Additional versions of Python 3 are distributed as non-modular RPM packages with a shorter life cycle through the AppStream repository in minor RHEL 9 releases. You can install these additional Python 3 versions in parallel with Python 3.9.
Python 2 is not distributed with RHEL 9.
| Version | Package to install | Command examples | Available since | Life cycle |
|---|---|---|---|---|
| Python 3.9 |
|
| RHEL 9.0 | full RHEL 9 |
| Python 3.11 |
|
| RHEL 9.2 | shorter |
| Python 3.12 |
|
| RHEL 9.4 | shorter |
For details about the length of support, see Red Hat Enterprise Linux Life Cycle and Red Hat Enterprise Linux Application Streams Life Cycle.
1.2. Major differences in the Python ecosystem since RHEL 8 Copy linkLink copied to clipboard!
RHEL 9 introduces several major changes in the Python ecosystem compared to RHEL 8, including the unversioned python command and architecture-specific Python wheels.
- The unversioned
pythoncommand -
The unversioned form of the
pythoncommand (/usr/bin/python) is available in thepython-unversioned-commandpackage. On some systems, this package is not installed by default. To install the unversioned form of thepythoncommand manually, use thednf install /usr/bin/pythoncommand.
In RHEL 9, the unversioned form of the python command points to the default Python 3.9 version and it is an equivalent to the python3 and python3.9 commands. In RHEL 9, you cannot configure the unversioned command to point to a different version than Python 3.9.
The python command is intended for interactive sessions. In production, it is recommended to use python3, python3.9, python3.11, or python3.12 explicitly.
You can uninstall the unversioned python command by using the dnf remove /usr/bin/python command.
If you need a different python or python3 command, you can create custom symlinks in /usr/local/bin or ~/.local/bin, or use a Python virtual environment.
Several other unversioned commands are available, such as /usr/bin/pip in the python3-pip package. In RHEL 9, all unversioned commands point to the default Python 3.9 version.
- Architecture-specific Python
wheels -
Architecture-specific Python
wheelsbuilt on RHEL 9 newly adhere to the upstream architecture naming, which allows customers to build their Pythonwheelson RHEL 9 and install them on non-RHEL systems. Pythonwheelsbuilt on previous releases of RHEL are compatible with later versions and can be installed on RHEL 9. Note that this affects onlywheelscontaining Python extensions, which are built for each architecture, not Pythonwheelswith pure Python code, which is not architecture-specific.
Chapter 2. Installing and using Python Copy linkLink copied to clipboard!
In RHEL 9, Python 3.9 is the default Python implementation. Since RHEL 9.2, Python 3.11 is available as the python3.11 package suite, and since RHEL 9.4, Python 3.12 as the python3.12 package suite.
The unversioned python command points to the default Python 3.9 version.
2.1. Installing Python 3 Copy linkLink copied to clipboard!
The default Python implementation is usually installed by default. To install it manually, use the following procedure.
Procedure
To install Python 3.9, use:
# dnf install python3.9To install Python 3.11, use:
# dnf install python3.11To install Python 3.12, use:
# dnf install python3.12
Verification
-
To verify the Python version installed on your system, use the
--versionoption with thepythoncommand specific for your required version of Python. For Python 3.9:
$ python3.9 --versionFor Python 3.11:
$ python3.11 --versionFor Python 3.12:
$ python3.12 --version
2.2. Installing additional Python 3 packages Copy linkLink copied to clipboard!
Packages prefixed with python3- contain add-on modules for the default Python 3.9 version. Packages prefixed with python3.11- contain add-on modules for Python 3.11. Packages prefixed with python3.12- contain add-on modules for Python 3.12.
Procedure
To install the
Requestsmodule for Python 3.9, use:# dnf install python3.9-requestsTo install the
pippackage installer from Python 3.9, use:# dnf install python3.9-pipTo install the
pippackage installer from Python 3.11, use:# dnf install python3.11-pipTo install the
pippackage installer from Python 3.12, use:# dnf install python3.12-pip
2.3. Installing additional Python 3 tools for developers Copy linkLink copied to clipboard!
Additional Python tools for developers are distributed mostly through the CodeReady Linux Builder (CRB) repository.
The python3-pytest package and its dependencies are available in the AppStream repository.
The CRB repository contains, for example, the following packages:
-
python3*-idle -
python3*-debug -
python3*-Cython -
python3.11-pytestand its dependencies -
python3.12-pytestand its dependencies.
The content in the CodeReady Linux Builder repository is unsupported by Red Hat.
Not all upstream Python-related packages are available in RHEL.
To install packages from the CRB repository, use the following procedure.
Procedure
Enable the CodeReady Linux Builder repository:
# subscription-manager repos --enable codeready-builder-for-rhel-9-x86_64-rpmsInstall the
python3*-Cythonpackage:For Python 3.9:
# dnf install python3.9-CythonFor Python 3.11:
# dnf install python3.11-CythonFor Python 3.12:
# dnf install python3.12-Cython
2.4. Using Python Copy linkLink copied to clipboard!
Examples show how to run the Python interpreter and Python-related commands. The examples cover Python 3.9, 3.11, and 3.12, including starting the interpreter, using virtual environments, and installing packages with pip.
Prerequisites
- Ensure that Python is installed.
-
If you want to download and install third-party applications for Python 3.11 or Python 3.12, install the
python3.11-piporpython3.12-pippackage.
Installing Python packages with pip as the root user places files in system locations. This can override RHEL libraries and might cause system instability or conflicts with supported packages. Red Hat does not support software installed by using pip at the system level. To avoid these issues, use pip within a virtual environment or install packages as a non-root user with the --user option.
Procedure
To run the Python 3.9 interpreter or related commands, use, for example:
$ python3.9 $ python3.9 -m venv --help $ python3.9 -m pip install package $ pip3 install packageTo run the Python 3.11 interpreter or related commands, use, for example:
$ python3.11 $ python3.11 -m venv --help $ python3.11 -m pip install package $ pip3.11 install packageTo run the Python 3.12 interpreter or related commands, use, for example:
$ python3.12 $ python3.12 -m venv --help $ python3.12 -m pip install package $ pip3.12 install package
Chapter 3. Packaging Python 3 RPMs Copy linkLink copied to clipboard!
You can install Python packages on your system either from the upstream PyPI repository using the pip installer, or using the DNF package manager. DNF uses the RPM package format, which offers more downstream control over the software.
The packaging format of native Python packages is defined by Python Packaging Authority (PyPA) Specifications. Most Python projects use the distutils or setuptools utilities for packaging, and defined package information in the setup.py file. However, possibilities of creating native Python packages have evolved over time. For more information about emerging packaging standards, see pyproject-rpm-macros.
Packaging a Python project that uses setup.py into an RPM provides the following advantages compared to native Python packages:
-
Dependencies on Python and non-Python packages are possible and strictly enforced by the
DNFpackage manager. - You can cryptographically sign the packages. With cryptographic signing, you can verify, integrate, and test content of RPM packages with the rest of the operating system.
- You can execute tests during the build process.
3.1. SPEC file description for a Python package Copy linkLink copied to clipboard!
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)
An RPM SPEC file for Python projects has some specifics compared to non-Python RPM SPEC files.
A name of any RPM package of a Python library must always include the python3-, python3.11-, or python3.12- prefix.
Other specifics are shown in the following SPEC file example for the python3*-pello package. For description of such specifics, see the notes below the example.
An example spec file for the program written in Python
%global python3_pkgversion 3.12
Name: python-pello
Version: 1.0.2
Release: 1%{?dist}
Summary: Example Python library
License: MIT
URL: https://github.com/fedora-python/Pello
Source: %{url}/archive/v%{version}/Pello-%{version}.tar.gz
BuildArch: noarch
BuildRequires: python%{python3_pkgversion}-devel
# Build dependencies needed to be specified manually
BuildRequires: python%{python3_pkgversion}-setuptools
# Test dependencies needed to be specified manually
# Also runtime dependencies need to be BuildRequired manually to run tests during build
BuildRequires: python%{python3_pkgversion}-pytest >= 3
%global _description %{expand:
Pello is an example package with an executable that prints Hello World! on the command line.}
%description %_description
%package -n python%{python3_pkgversion}-pello
Summary: %{summary}
%description -n python%{python3_pkgversion}-pello %_description
%prep
%autosetup -p1 -n Pello-%{version}
%build
# The macro only supported projects with setup.py
%py3_build
%install
# The macro only supported projects with setup.py
%py3_install
%check
%{pytest}
# Note that there is no %%files section for the unversioned python module
%files -n python%{python3_pkgversion}-pello
%doc README.md
%license LICENSE.txt
%{_bindir}/pello_greeting
# The library files needed to be listed manually
%{python3_sitelib}/pello/
# The metadata files needed to be listed manually
%{python3_sitelib}/Pello-*.egg-info/
%changelog
* Tue May 31 2016 Adam Miller <maxamillion@fedoraproject.org> - 1.0.2-1
- First pello package
- 1
- By defining the
python3_pkgversionmacro, you set which Python version this package will be built for. To build for the default Python version 3.9, either set the macro to its default value3or remove the line entirely. - 2
- When packaging a Python project into RPM, always add the
python-prefix to the original name of the project. The original name here ispelloand, therefore, the name of the Source RPM (SRPM) ispython-pello. - 3
- The
BuildRequiresdirective specifies what packages are required to build and test this package. InBuildRequires, always include items providing tools necessary for building Python packages:python3-devel(orpython3.11-develorpython3.12-devel) and the relevant packages needed by the specific software that you package, for example,python3-setuptools(orpython3.11-setuptoolsorpython3.12-setuptools) or the runtime and testing dependencies needed to run the tests in the%checksection. - 4
- When choosing a name for the binary RPM (the package that users will be able to install), add a versioned Python prefix. Use the
python3-prefix for the default Python 3.9, thepython3.11-prefix for Python 3.11, or thepython3.12-prefix for Python 3.12. You can use the%{python3_pkgversion}macro, which evaluates to3for the default Python version 3.9 unless you set it to an explicit version, for example,3.11(see footnote 1). - 5
- The
%py3_buildand%py3_installmacros run thesetup.py buildandsetup.py installcommands, respectively, with additional arguments to specify installation locations, the interpreter to use, and other details. - 6
- The
%checksection should run the tests of the packaged project. The exact command depends on the project itself, but it is possible to use the%pytestmacro to run thepytestcommand in an RPM-friendly way.
3.2. Common macros for Python 3 RPMs Copy linkLink copied to clipboard!
In a SPEC file, always use the macros that are described in the following Macros for Python 3 RPMs table rather than hardcoding their values. You can redefine which Python 3 version is used in these macros by defining the python3_pkgversion macro on top of your SPEC file (see Section 3.1, “SPEC file description for a Python package”). If you define the python3_pkgversion macro, the values of the macros described in the following table will reflect the specified Python 3 version.
| Macro | Normal Definition | Description |
|---|---|---|
| %{python3_pkgversion} | 3 |
The Python version that is used by all other macros. Can be redefined to |
| %{python3} | /usr/bin/python3 | The Python 3 interpreter |
| %{python3_version} | 3.9 | The major.minor version of the Python 3 interpreter |
| %{python3_sitelib} | /usr/lib/python3.9/site-packages | The location where pure-Python modules are installed |
| %{python3_sitearch} | /usr/lib64/python3.9/site-packages | The location where modules containing architecture-specific extension modules are installed |
| %py3_build |
Runs the | |
| %py3_install |
Runs the | |
| %{py3_shebang_flags} | s |
The default set of flags for the Python interpreter directives macro, |
| %py3_shebang_fix |
Changes Python interpreter directives to |
3.3. Using automatically generated dependencies for Python RPMs Copy linkLink copied to clipboard!
The following procedure describes how to use automatically generated dependencies when packaging a Python project as an RPM.
Prerequisites
- A SPEC file for the RPM exists. For more information, see SPEC file description for a Python package.
Procedure
Make sure that one of the following directories containing upstream-provided metadata is included in the resulting RPM:
-
.dist-info .egg-infoThe RPM build process automatically generates virtual
pythonX.Ydistprovides from these directories, for example:python3.9dist(pello)The Python dependency generator then reads the upstream metadata and generates runtime requirements for each RPM package using the generated
pythonX.Ydistvirtual provides. For example, a generated requirements tag might look as follows:Requires: python3.9dist(requests)
-
- Inspect the generated requires.
To remove some of the generated requires, use one of the following approaches:
-
Modify the upstream-provided metadata in the
%prepsection of the SPEC file. - Use automatic filtering of dependencies described in the upstream documentation.
-
Modify the upstream-provided metadata in the
-
To disable the automatic dependency generator, include the
%{?python_disable_dependency_generator}macro above the main package’s%descriptiondeclaration.
Chapter 4. Handling interpreter directives in Python scripts Copy linkLink copied to clipboard!
In Red Hat Enterprise Linux 9, executable Python scripts are expected to use interpreter directives (also known as hashbangs or shebangs) that explicitly specify at a minimum the major Python version. For example:
#!/usr/bin/python3.9
#!/usr/bin/python3.11
#!/usr/bin/python3.12
The /usr/lib/rpm/redhat/brp-mangle-shebangs buildroot policy (BRP) script is run automatically when building any RPM package, and attempts to correct interpreter directives in all executable files.
The BRP script generates errors when encountering a Python script with an ambiguous interpreter directive, such as:
#!/usr/bin/python
or
#!/usr/bin/env python
4.1. Modifying interpreter directives in Python scripts Copy linkLink copied to clipboard!
Use the following procedure to modify interpreter directives in Python scripts that cause build errors at RPM build time.
Prerequisites
- Some of the interpreter directives in your Python scripts cause a build error.
Procedure
To modify interpreter directives, complete one of the following tasks:
Use the following macro in the
%prepsection of your SPEC file:# %py3_shebang_fix SCRIPTNAME …SCRIPTNAME can be any file, directory, or a list of files and directories.
As a result, all listed files and all
.pyfiles in listed directories will have their interpreter directives modified to point to%{python3}. Existing flags from the original interpreter directive will be preserved and additional flags defined in the%{py3_shebang_flags}macro will be added. You can redefine the%{py3_shebang_flags}macro in your SPEC file to change the flags that will be added.Apply the
pathfix.pyscript from thepython3-develpackage:# pathfix.py -pn -i %{python3} PATH …You can specify multiple paths. If a
PATHis a directory,pathfix.pyrecursively scans for any Python scripts matching the pattern^[a-zA-Z0-9_]+\.py$, not only those with an ambiguous interpreter directive. Add the command above to the%prepsection or at the end of the%installsection.-
Modify the packaged Python scripts so that they conform to the expected format. For this purpose, you can use the
pathfix.pyscript outside the RPM build process, too. When runningpathfix.pyoutside an RPM build, replace%{python3}from the preceding example with a path for the interpreter directive, such as/usr/bin/python3or/usr/bin/python3.11.
Chapter 5. Installing Tcl/Tk Copy linkLink copied to clipboard!
Tcl is a dynamic programming language, and Tk is a graphical user interface (GUI) toolkit. Install Tcl and Tk on Red Hat Enterprise Linux for dynamic scripting and graphical interfaces.
5.1. Introduction to Tcl/Tk Copy linkLink copied to clipboard!
Tcl is a dynamic programming language, while Tk is a graphical user interface (GUI) toolkit. They provide a powerful and easy-to-use platform for developing cross-platform applications with graphical interfaces. As a dynamic programming language, 'Tcl' provides simple and flexible syntax for writing scripts. The tcl package provides the interpreter for this language and the C library. You can use Tk as GUI toolkit that provides a set of tools and widgets for creating graphical interfaces. You can use various user interface elements such as buttons, menus, dialog boxes, text boxes, and canvas for drawing graphics. Tk is the GUI for many dynamic programming languages.
For more information about Tcl/Tk, see the Tcl/Tk manual or Tcl/Tk documentation web page.
5.2. Installing Tcl Copy linkLink copied to clipboard!
The default Tcl implementation is usually installed by default. To install it manually, use the following procedure.
Procedure
To install
Tcl, use:# dnf install tcl
Verification
To verify the Tcl version installed on your system, run the interpreter
tclsh.$ tclshIn the interpreter run this command:
% info patchlevel 8.6- You can exit the interpreter interface by pressing Ctrl+C
5.3. Installing Tk Copy linkLink copied to clipboard!
The default Tk implementation is usually installed by default. To install it manually, use the following procedure.
Procedure
To install
Tk, use:# dnf install tk
Verification
To verify the
Tkversion installed on your system, run the window shellwish. You need to be running a graphical display.$ wishIn the shell run this command:
% puts $tk_version 8.6- You can exit the interpreter interface by pressing Ctrl+C
Chapter 6. Using the PHP scripting language Copy linkLink copied to clipboard!
Hypertext Preprocessor (PHP) is a general-purpose scripting language mainly used for server-side scripting. Install PHP and run PHP code using a web server or the command-line interface.
6.1. Installing the PHP scripting language Copy linkLink copied to clipboard!
In RHEL 9, PHP is available as the php RPM package (PHP 8.0), the php:8.1 module stream (PHP 8.1), or the php:8.2 module stream (PHP 8.2).
Procedure
To install PHP 8.0, enter:
# dnf install phpTo install the
php:8.1orphp:8.2module stream with the default profile, enter for example:# dnf module install php:8.1
The default common profile installs also the php-fpm package, and preconfigures PHP for use with the Apache HTTP Server or nginx.
To install a specific profile of the
php:8.1orphp:8.2module stream, use for example:# dnf module install php:8.1/profileThe available profiles for the
php:8.1andphp:8.2module streams are:-
common- The default profile for server-side scripting using a web server. It includes the most widely used extensions. -
minimal- This profile installs only the command line for scripting with PHP without using a web server. -
devel- This profile includes packages from the common profile and additional packages for development purposes.
-
For example, to install PHP 8.1 for use without a web server, use:
# dnf module install php:8.1/minimal
6.2. Using the PHP scripting language with a web server Copy linkLink copied to clipboard!
6.2.1. Using PHP with the Apache HTTP Server Copy linkLink copied to clipboard!
In Red Hat Enterprise Linux 9, the Apache HTTP Server runs PHP by using FastCGI Process Manager (FPM) by default. Install and configure Apache with PHP.
Prerequisites
- The PHP scripting language is installed on your system.
Procedure
Install the
httpdpackage:# dnf install httpdStart the
Apache HTTP Server:# systemctl start httpd-
Or, if the
Apache HTTP Serveris already running on your system, restart thehttpdservice after installing PHP:
-
Or, if the
# systemctl restart httpd
Start the
php-fpmservice:# systemctl start php-fpmOptional: Enable both services to start at boot time:
# systemctl enable php-fpm httpdTo obtain information about your PHP settings, create the
index.phpfile with the following content in the/var/www/html/directory:# echo '<?php phpinfo(); ?>' > /var/www/html/index.phpTo run the
index.phpfile, point the browser to:http://<hostname>/Optional: Adjust configuration if you have specific requirements:
-
/etc/httpd/conf/httpd.conf- generichttpdconfiguration -
/etc/httpd/conf.d/php.conf- PHP-specific configuration forhttpd -
/usr/lib/systemd/system/httpd.service.d/php-fpm.conf- by default, thephp-fpmservice is started withhttpd -
/etc/php-fpm.conf- FPM main configuration -
/etc/php-fpm.d/www.conf- defaultwwwpool configuration
-
Example 6.1. Running a "Hello, World!" PHP script using the Apache HTTP Server
Create a
hellodirectory for your project in the/var/www/html/directory:# mkdir helloCreate a
hello.phpfile in the/var/www/html/hello/directory with the following content:# <!DOCTYPE html> <html> <head> <title>Hello, World! Page</title> </head> <body> <?php echo 'Hello, World!'; ?> </body> </html>Start the
Apache HTTP Server:# systemctl start httpdTo run the
hello.phpfile, point the browser to:http://<hostname>/hello/hello.php
As a result, a web page with the “Hello, World!" text is displayed.
6.2.2. Using PHP with the nginx web server Copy linkLink copied to clipboard!
You can run PHP code through the nginx web server. The steps below show how to install and configure nginx with PHP.
Prerequisites
- The PHP scripting language is installed on your system.
Procedure
Install the
nginxpackage:# dnf install nginxStart the
nginxserver, or if it is already running, restart thenginxservice after installing PHP:# systemctl start nginx# systemctl restart nginxStart the
php-fpmservice:# systemctl start php-fpmOptional: Enable both services to start at boot time:
# systemctl enable php-fpm nginxTo obtain information about your PHP settings, create the
index.phpfile with the following content in the/usr/share/nginx/html/directory:# echo '<?php phpinfo(); ?>' > /usr/share/nginx/html/index.phpTo run the
index.phpfile, point the browser to:http://<hostname>/Optional: Adjust configuration if you have specific requirements:
-
/etc/nginx/nginx.conf-nginxmain configuration -
/etc/nginx/conf.d/php-fpm.conf- FPM configuration fornginx -
/etc/php-fpm.conf- FPM main configuration -
/etc/php-fpm.d/www.conf- defaultwwwpool configuration
-
Example — Running a "Hello, World!" PHP script: Create a
hellodirectory for your project in the/usr/share/nginx/html/directory:# mkdir helloCreate a
hello.phpfile in the/usr/share/nginx/html/hello/directory with the following content:# <!DOCTYPE html> <html> <head> <title>Hello, World! Page</title> </head> <body> <?php echo 'Hello, World!'; ?> </body> </html>Start the
nginxserver:# systemctl start nginxTo run the
hello.phpfile, point the browser to:http://<hostname>/hello/hello.phpAs a result, a web page with the “Hello, World!" text is displayed.
6.3. Running a PHP script using the command line Copy linkLink copied to clipboard!
Run a PHP script from the command line to automate tasks or test code without using a web server.
Prerequisites
- The PHP scripting language is installed on your system.
Procedure
In a text editor, create a
filename.phpfileReplace filename with the name of your file.
Execute the created
filename.phpfile from the command line:# php filename.phpExample — Running a "Hello, World!" PHP script: Create a
hello.phpfile with the following content using a text editor:<?php echo 'Hello, World!'; ?>Execute the
hello.phpfile from the command line. "Hello, World!" is printed:# php hello.php
6.4. Additional resources Copy linkLink copied to clipboard!
-
httpd(8)- The manual page for thehttpdservice containing the complete list of its command-line options. -
httpd.conf(5)- The manual page forhttpdconfiguration, describing the structure and location of thehttpdconfiguration files. -
nginx(8)- The manual page for thenginxweb server containing the complete list of its command-line options and list of signals. -
php-fpm(8)- The manual page for PHP FPM describing the complete list of its command-line options and configuration files.