Red Hat Summit7장. Packaging Python 3 RPMs
You can install Python packages on your system by using the DNF package manager. DNF uses the RPM package format, which offers more downstream control over the software.
Packaging a Python project into an RPM package provides the following advantages compared to native Python packages:
- Dependencies on Python and non-Python packages are possible and strictly enforced by the DNF package manager.
- You can cryptographically sign the packages. With cryptographic signing, you can verify, integrate, and test contents of RPM packages with the rest of the operating system.
- You can execute tests during the build process.
The packaging format of native Python packages is defined by Python Packaging Authority (PyPA) Specifications. Historically, most Python projects used 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:
-
To package Python software that uses the
setup.pyfile, follow this document. -
To package more modern packages with
pyproject.tomlfiles, see theREADMEfile in pyproject-rpm-macros. Note thatpyproject-rpm-macrosis included in the CodeReady Linux Builder (CRB) repository, which contains unsupported packages, and it can change over time to support newer Python packaging standards.
7.1. A spec file description for an example Python package
An RPM spec file for Python projects has some specifics compared to non-Python RPM spec files.
Note that it is recommended for any RPM package name of a Python library to include the python3- prefix.
See the notes about Python RPM spec files specifics in the following example of the python3-pello package.
- An example SPEC file for the pello program written in Python
%global python3_pkgversion 3
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 need to be specified manually
BuildRequires: python%{python3_pkgversion}-setuptools
# Test dependencies need to be specified manually
# 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 supports projects with setup.py
%py3_build
%install
# The macro only supports projects with setup.py
%py3_install
%check
%pytest
# Note that there is no %%files section for python-pello
%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/- 1
- By defining the
python3_pkgversionmacro, you set which Python version this package will be built for. To build for the default Python version3.12, remove the line. - 2
- When packaging a Python project into RPM, always add the
python-prefix to the original name of the project. The project name here isPelloand, therefore, the name of the Source RPM (SRPM) ispython-pello. - 3
BuildRequiresspecifies what packages are required to build and test this package. InBuildRequires, always include items providing tools necessary for building Python packages:python3-develand the relevant projects needed by the specific software that you package, for example,python3-setuptoolsor 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.12. You can use the%{python3_pkgversion}macro, which evaluates to3for the default Python version3.12unless you set it to an explicit version, for example, when a later version of Python is available (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.참고Using the
setup.py buildandsetup.py installcommands from thesetuptoolspackage is deprecated and will be removed in the future major RHEL release. You can use pyproject-rpm-macros instead. - 6
- The
%checksection runs the tests of the packaged project. The exact command depends on the project itself, but you can use the%pytestmacro to run thepytestcommand in an RPM-friendly way.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}