From Fedora Project Wiki

Deciding when to package for a multiple Python runtimes

Applications Application foo is not meant to be used within others python libraries via import foo and both python3 and python2 versions of foo provides same functionality and therefore only one version is needed. This also includes scripts. DevAssistant is an *application* - We invoke DA and we don't care if it is python2 and python3 based, both will fulfill our task.

Applications Exceptions On the other hand, pip isn't application even though it s not meant to be used via import statement because both python3 and python2 versions provides different functionality (python-pip installs python2 packages and python3-pip installs python3 packages), therefore it is an *exception*.

Modules Modules are meant to be used via import statement in other python libraries and therefore both python2 and python3 (and any others future majors) versions are needed

Both modules and applications exceptions should be packaged for every major python runtime available if supported by upstream.

Packaging Applications (single Python runtime)

Python3 runtime
When packaging only for a single Python runtime you are obligated to use a python3 version of the runtime but only if upstream supports it.

When packaging an application you should use a python runtime which is default for a given Fedora release (python3 for Fedora23) but only if the application support this python runtime. To accomplish this we can use the unversioned python macros in a specportable manner accross different Fedora releases and EPEL.

%global pypi_name devassistant

Name:           %{pypi_name}
Version:        0.11.1
Release:        1%{?dist}
Summary:        DevAssistant helps you kickstart your projects with ease

License:        GPLv2+
BuildArch:      noarch

BuildRequires:  python%{?py_default_major}-devel
BuildRequires:  python%{?py_default_major}-setuptools
BuildRequires:  python%{?py_default_major}-sphinx

Requires:       python%{?py_default_major}-setuptools

DevAssistant ( can help you with creating and setting up basic projects in
various languages, installing dependencies, setting up environment etc.
It is based on idea of per-{language/framework/…} “assistants” (plugins) with hierarchical structure.

%setup -q -n %{pypi_name}-%{version}
# Remove bundled egg-info
rm -rf %{pypi_name}.egg-info

# generate html docs 
sphinx-build docs html
# remove the sphinx-build leftovers
rm -rf html/.{doctrees,buildinfo}

%{__python} build

%{__python} install --skip-build --root %{buildroot}

%doc html README.rst LICENSE devassistant/dapi/ test/fixtures/doc/c/LICENSE

* Wed May 13 2015 John Doe <> - 0.11.1-1
- Initial package.

Example of specfile used to build an application with a default python in a way that it may be built accross different Fedora release versions and even within EPEL without any changes neccessary. Note the usage of unversioned macros: __python, python_sitelib and special macro for listing a requires py_default_major which expands on Fedora23 to value 3 so python%{?py_default_major}-devel will become a python3-devel and is ignored on others (hence expanding to python-devel).

Packaging for multiple Python runtimes

Many times when you package a python module you will want to create a module for all major python runtimes available. 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 source code for every major version of python is distributed as a single tarball (many times as a single directory of source where for example the /usr/bin/2to3 program is used to transform python2 code to python3 at buildtime) then you must package them as subpackages built from a single SRPM.

Multiple SRPMS