F21/F22 System Wide Change: Python 3 as the Default Implementation

[Jaroslav Reznik]

= Proposed System Wide Change: Python 3 as the Default Implementation =
https://fedoraproject.org/wiki/Changes/Python_3_as_Default

Note: Change requested by FESCo in advance for targeted Fedora.

Change owner(s): Slavek Kabrda <bkabrda at redhat.com>, Matej Stuchlik 
<mstuchli at redhat.com>

Up until now, Fedora has used Python 2 as the default Python implementation. 
This change proposes switching to Python 3. The details of the term 
"switching" are explained thoroughly in the Scope section.

== Detailed description ==
Python 3 is the next generation of Python programming language. It is 
currently mature and stable, since it has been under active development for 
five years - version 3.0 was released in December 2008, current latest stable 
version is 3.3.2 released in May 2013. The main reason to switch to Python 3 
as the default implementation is that Python 2 is in maintenance mode, thus 
only bugfixes and security fixes are accepted upstream. Further reasons are 
mentioned in the Benefit to Fedora section. For this Change to be carried out 
successfully, it is necessary that the key packages in the Fedora software 
stack be ported to Python 3. These are parts of the minimal buildroot, the 
default package manager, programs present on the LiveCD etc. More information 
on the packages involved can be found in Dependencies. While porting of some 
packages is rather trivial, other packages need significant amount of work to 
get rid of the Python 2 dependence. 

== Scope ==
The main goal is switching to Python 3 as a default, in which state:
* DNF is the default package manager instead of Yum, which only works with 
Python 2
* Python 3 is the only Python implementation in the minimal buildroot
* Python 3 is the only Python implementation on the LiveCD
* Anaconda and all of its dependencies run on Python 3
* cloud-init and all of its dependencies run on Python 3
(see Dependencies for the list of packages that need to be ported)

This will also require revisiting Python guidelines (broader discussion with 
community and FPC approval - TBD). The result of the discussion will reflect in 
this Change in further instructions for Fedora packagers.

There are basically two types of packages that need to undergo the conversion:
* Python extension modules and libraries that provide Python bindings - 
assuming that there is upstream support, these can receive python3- subpackage 
anytime without any damage to Fedora; we can then just utilize this subpackage 
when switching to Python 3 (instead of using current python- subpackage).
* Packages that build with some sort of "embedded Python support", like gdb, 
or Rhythmbox with its plugins. In these cases, it makes no sense to do a 
python3- subpackage, since the whole package would need to be duplicated (e.g. 
python3-gdb). These packages should be tested with Python 3 locally without 
any modifications to how they're currently built in Fedora. When we get a Koji 
side tag, these packages will switch and build against Python 3 in the side 
tag.

==== Work in Fedora 21 Timeframe ====
* Proposal owners:
** Discussing changes in Python packaging guidelines with Fedora community and 
FPC
** Helping upstreams with porting to Python 3
** Introducing python3- packages where appropriate, testing packages that only 
build with Python once (e.g. gdb, Rhythmbox)

* Other developers:
** Hopefully the same as proposal owners.

* Release engineering:
** Nothing in F21 timeframe

* Policies and guidelines:
** As mentioned above, this will require a discussion with community and FPC 
and preparation of changes to Python packaging guidelines. The changes related 
to the actual switch should however be merged in F22 timeframe and only if the 
switch is successful.

==== Work in Fedora 22 Timeframe ====
* Proposal owners:
** Continue the work from F21 timeframe
** Request Koji side tag and encourage packagers to rebuilt their packages 
with Python 3 there
** If the switch to Python 3 is achieved in the side tag:
*** Modify comps accordingly
*** Apply the changes to Python packaging guidelines
*** Ask relengs to merge the side tag into F22
** Else:
*** Postpone the Change for another release
*** Do not merge side tag into F22
*** Do not apply changes to Python packaging guidelines

* Other developers:
** Introduce python3- subpackages where appropriate, build against Python 3 in 
the side tag where appropriate

* Release engineering:
** Create the Koji side tag
** Merge the side tag back in F22 if the switch is achieved

* Policies and guidelines:
** Apply the changes to Python guidelines if the switch is achieved