In Fedora we have multiple python runtimes, one for each supported major release. At this point that’s one for python2.x and one for python3.x. If a piece of software supports python3, it must be packaged for python3. If it supports python2 as well, it may be packaged for python2. If it supports only python2 then it must not be packaged for python3.

Each runtime corresponds to a binary of the form /usr/bin/python$MAJOR.$MINOR One of these python runtimes is the "system runtime" which is what is run when invoking /usr/bin/python. On Fedora 21 this is a link to /usr/bin/python2 (which itself is a link to /usr/bin/python2.7).

However, packages in Fedora should not depend on where /usr/bin/python happens to point but instead should call the proper executable for the needed python major version directly, either /usr/bin/python2 or /usr/bin/python3 as appropriate.

All python runtimes have a virtual provide for python(abi) = $MAJOR-$MINOR. For example, the python-3.1 runtime rpm has:

` $ rpm -q --provides python3 |grep -i abi`
` python(abi) = 3.1`

python modules using these runtimes should have a corresponding "Requires" line on the python runtime that they are used with. This is done automatically for files below /usr/lib[^/]*/python${PYVER}

To build a package containing python2 files, you need to have

Similarly, when building a package which ships python3 files, you need

A package that has both python2 and python3 files will need to BuildRequire both.

Python2 packages need to provide a python2 version of their name. So, for example, a python package of the "foo" module needs to include Provides: python2-foo.

In RHEL 6 and older, python2 packages that install python modules need to define __python2, python2_sitelib, and python2_sitearch macros. This is not needed in current Fedora or with python3 modules as the macros are defined by rpm and the python3-devel package. To define those conditionally you can use this:

Note that the use of %{!? […​]} does allow this to work without the check for rhel versions but putting the conditional in documents when we can remove the entire stanza from the spec file.

In Fedora, the following macros are defined for you:

During %install or when listing %files you can use the python2_sitearch and python2_sitelib macros to specify where the installed modules are to be found. For instance:

Using the macros has several benefits.

When installing python modules we include several different types of files.

Source files (*.py) must be included in the same packages as the byte-compiled versions of them.

Python will automatically try to byte compile files when it runs in order to speed up startup the next time it is run. These files are saved in files with the extension of .pyc (compiled python) or .pyo (optimized compiled python). With current versions of python 3, these files will be located inside a directory named pycache. Older versions of python will simply place them alongside the .py files.

The .pyc and .pyo files contain byte code that is portable across OSes. If you do not include them in your packages, python will try (and generally fail) to create them when the user runs the program. If the system administrator runs the program, then the files will be successfully written, causing stray .pyc and .pyo files which will not be removed when the package is removed. To prevent that the byte compiled files need to be compiled and included in the %files section. Normally, byte compilation is done for you by the brp-python-bytecompile script. This script runs after the %install section of the spec file has been processed and byte compiles any .py files that it finds (this recompilation puts the proper filesystem paths into the modules otherwise tracebacks would include the %{buildroot} in them).

You must include in your package the .pyc and .pyo files. If the build process creates a pycache directory in a subdirectory of %{python3_sitearch} or %{python3_sitelib}, you must also include all items in the pycache directory. (You should not include the directories %{python3_sitearch}/pycache or %{python3_sitelib}/pycache because they are already owned by the python3-libs package.)

All that you need to do is include the files in the %files section (replacing %{python3_sitelib} with the appropriate macro for your package):

or, if the python code installs directly into %{python3_sitelib}:

Many times when you package a python module you will want to create a module for python2 and a module for python3. There are two ways of doing this: either from a single SRPM or from multiple. The rule to choose which method is simple: if the python2 and python3 modules are distributed as a single tarball (many times as a single directory of source where the /usr/bin/2to3 program is used to transform the code at buildtime) then you must package them as subpackages built from a single SRPM. If they come in multiple tarballs then package them from multiple SRPMs.

The python 2 and python 3 stacks are intended to be fully-installable in parallel. When generalizing the package for both python 2 and python 3, it is important to ensure that two different built packages do not attempt to place different payloads into the same path.

Eggs can mean several different things because they can be placed on disk in several formats:

In Fedora packages, these will be installed to %{python2_sitelib} or %{python2_sitearch} directories. We do not install the single zip file version of eggs in Fedora but the three other formats are used.

RPM’s dependency generator can often throw in additional dependencies and will often think packages provide functionality contrary to reality. To fix this, the dependency generator needs to be overriden so that the additional dependencies can be filtered out. See Packaging:AutoProvidesAndRequiresFiltering for details.