Many Python 2 modules were removed from the distribution: packages that only provide Python 2 importable modules, if they are not used by any other package (leaf packages).
While this change should not affect regular users, it will affect developers that use system-packaged Python modules.
If you are developing software that needs to run with Python 2, we recommend
using a virtual environment and installing dependencies from the Python
Package index (
PyPI). See details at:
We also recommend using a virtual environment (
venv) for Python 3, if your
software targets the wider Python ecosystem rather than Fedora
venv will decouple your development environment from
If you are developing for a Fedora package, please port to Python 3 as soon as possible. Almost complete Python 2 removal is planned for the next release.
The generator which generates Provides and Requires for Python RPM packages
based on the
setup.py file has been enabled by default. This makes the
packaging of Python packages easier and more automatic by reusing
information provided by the upstream project, and should result in fewer
unecessary or missing dependencies in RPMs.
progressbar package has been updated to use the
which is newer and better maitained.
As part of the general move to Python 3, extensions for the file browser and graphical shell Nautilus are now executed using Python 3, and extensions compatible only with Python 2 are no longer supported. Extensions packaged in the distribution have been updated for Python 3 compatiblity. Users who have installed their own extensions should check that they are compatible with Python 3 or remove them.
When extension modules are built, the
distutils module provides a set of
compilation and link flags to ensure that modules are compiled in a way
which is compatible with Python executable itself. When building modules in
Fedora, the same set of flags was used for modules which are part of the
distribution (i.e. part of an RPM package) and for modules compiled by users
using Fedora. Those flags included custom GCC plugins and additional
linker options to "harden" the code and add
annobin annotations, which is
appropriate for the distribution, but unexpected and unnecessary for user
code. A distinct and smaller set of flags is now provided for extension
modules compiled by users.
The build flags (
LDFLAGS) saved in the Python’s
distutils module for building extension modules are switched from:
means that no GCC plugins (such as annobin) are activated and no GCC spec
-specs= arguments) are used by default when building Python
extension modules (e.g. with
python3 setup.py build).
python3-devel package will lose its runtime dependency on
redhat-rpm-config (which was only required for annobin support and GCC
The change affects building extension modules by users, outside of the RPM
environment. The Python standard library and Fedora’s Python 3 RPM packages
are still built with the "traditional" set of flags (
etc.), unless the package uses nonstandard methods to build the extensions.
Only Python 3.7 and 3.6 will be changed.
For detailed information about this change, including justification and impact on Python developers and packages, see the Change page on the Wiki.