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)
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+ URL: https://github.com/bkabrda/devassistant Source0: https://pypi.python.org/packages/source/d/%{pypi_name}/%{pypi_name}-%{version}.tar.gz 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 %description DevAssistant (http://devassistant.org) 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. %prep %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} %build %{__python} setup.py build %install %{__python} setup.py install --skip-build --root %{buildroot} %files %doc html README.rst LICENSE devassistant/dapi/licenses.py test/fixtures/doc/c/LICENSE %{_bindir}/da %{_bindir}/da-gui %{_bindir}/devassistant %{_bindir}/devassistant-gui %{python_sitelib}/%{pypi_name} %{python_sitelib}/%{pypi_name}-%{version}-py?.?.egg-info %changelog * Wed May 13 2015 John Doe <jdoe@example.com> - 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
....