From Fedora Project Wiki
(Created page with "= Prelude = This page summarizes a proposal of changes to Python packaging guidelines, that should occur with switch to Python 3 as a default, as proposed in [1] (will be ref...")
 
No edit summary
Line 5: Line 5:
= Changes in Package Naming =
= Changes in Package Naming =


* Current state:
== Current State ==
python-* packages (built with Python 2) are installed by default (from LiveCD, as dependencies of applications that require some Python packages) and by <code>yum install python-foo</code>. Python 3 packages are named python3-* and are installed as <code>yum install python3-foo</code>.
python-* packages (built with Python 2) are installed by default (from LiveCD, as dependencies of applications that require some Python packages) and by <code>yum install python-foo</code>. Python 3 packages are named python3-* and are installed as <code>yum install python3-foo</code>.


From the packaging point of view, this is achieved by either
From the packaging point of view, this is achieved by either
## Having one SRPM python-foo that produces python-foo and python3-foo binary RPMs.
* Having one SRPM python-foo that produces python-foo and python3-foo binary RPMs.
or
or
## Having two SRPMs, python-foo (produces python-foo binary RPM) and python3-foo SRPM (produces python3-foo binary RPM).
* Having two SRPMs, python-foo (produces python-foo binary RPM) and python3-foo SRPM (produces python3-foo binary RPM).


* Future state implied by the ''Change'':
== Future State Implied by the ''Change'' ==
After the switch, python3-* packages are going to be installed by default (from LiveCD, as dependencies of applications that require some Python packages).
After the switch, python3-* packages are going to be installed by default (from LiveCD, as dependencies of applications that require some Python packages).


* Proposal for further changes:
== Proposal for Further Changes ==
** A brief discussion already happened at [2].
* A brief discussion already happened at [2].
** The SRPMs that produce binary RPMs for more Python runtimes should keep current names python-foo, the SRPMs that produce binary RPM for just one runtime should be named pythonX-foo.
* The SRPMs that produce binary RPMs for more Python runtimes should keep current names python-foo, the SRPMs that produce binary RPM for just one runtime should be named pythonX-foo.
** All the binary RPMs must be named pythonX-foo, where X is the major version of the Python runtime that they use.
* All the binary RPMs must be named pythonX-foo, where X is the major version of the Python runtime that they use.
** For the time being (and maybe forever), every python2-foo package must have <code>Provides: python-foo</code>.
* For the time being (and maybe forever), every python2-foo package must have <code>Provides: python-foo</code>.
** This means that from user's perspective only one thing will change, and that is python-* packages will be renamed to python2-*, but will still keep the provide of python-*.
* This means that from user's perspective only one thing will change, and that is python-* packages will be renamed to python2-*, but will still keep the provide of python-*.


* Why?
== Why? ==
** This concept will easily scale to more Python runtimes (PyPy, Jython), as already proposed previously by Tom Spur. Please note, that scaling to other runtimes is '''not''' part of this proposal and should be discussed further in another proposal/ML thread.
* This concept will easily scale to more Python runtimes (PyPy, Jython), as already proposed previously by Tom Spur. Please note, that scaling to other runtimes is '''not''' part of this proposal and should be discussed further in another proposal/ML thread.
** Currently, upstream recommendation [3] is to point /usr/bin/python to Python 2, but as the PEP notes, it will be reviewed and it is anticipated that in time it will be updated to recommend pointing /usr/bin/python to /usr/bin/python3. When this time comes, we should also move the provides suggested above (<code>Provides: python-foo</code>) from python2-* packages to python3-* packages to keep things like <code>yum install /usr/bin/python python-foo</code> consistent.
* Currently, upstream recommendation [3] is to point /usr/bin/python to Python 2, but as the PEP notes, it will be reviewed and it is anticipated that in time it will be updated to recommend pointing /usr/bin/python to /usr/bin/python3. When this time comes, we should also move the provides suggested above (<code>Provides: python-foo</code>) from python2-* packages to python3-* packages to keep things like <code>yum install /usr/bin/python python-foo</code> consistent.
** Having python2-* vs. python3-* packages is a good way of explicitly distinguishing packages from the two stacks. This is connected with the reason above - we should recommend using explicit usage of <code>/usr/bin/python{2,3}</code> and <code>yum install python{2,3}-foo</code>, and we should discourage use of implicit /usr/bin/python and python-* so that nothing breaks for users when these are changed in any way. (We already started to advertise usage of versioned /usr/bin/python{2,3} binary by deprecating %__python in current guidelines and recommending %__python{2,3}.)
* Having python2-* vs. python3-* packages is a good way of explicitly distinguishing packages from the two stacks. This is connected with the reason above - we should recommend using explicit usage of <code>/usr/bin/python{2,3}</code> and <code>yum install python{2,3}-foo</code>, and we should discourage use of implicit /usr/bin/python and python-* so that nothing breaks for users when these are changed in any way. (We already started to advertise usage of versioned /usr/bin/python{2,3} binary by deprecating %__python in current guidelines and recommending %__python{2,3}.)


* Alternatives
== Alternatives ==
** Just keep what we have - doesn't seem to scale to other Python runtimes;  
* Just keep what we have - doesn't seem to scale to other Python runtimes;  
** Only allow split SRPMs - too much maintenance work.
* Only allow split SRPMs - too much maintenance work.


[1] https://fedoraproject.org/wiki/Changes/Python_3_as_Default
[1] https://fedoraproject.org/wiki/Changes/Python_3_as_Default

Revision as of 11:11, 18 November 2013

Prelude

This page summarizes a proposal of changes to Python packaging guidelines, that should occur with switch to Python 3 as a default, as proposed in [1] (will be referred to as Change).

Changes in Package Naming

Current State

python-* packages (built with Python 2) are installed by default (from LiveCD, as dependencies of applications that require some Python packages) and by yum install python-foo. Python 3 packages are named python3-* and are installed as yum install python3-foo.

From the packaging point of view, this is achieved by either

  • Having one SRPM python-foo that produces python-foo and python3-foo binary RPMs.

or

  • Having two SRPMs, python-foo (produces python-foo binary RPM) and python3-foo SRPM (produces python3-foo binary RPM).

Future State Implied by the Change

After the switch, python3-* packages are going to be installed by default (from LiveCD, as dependencies of applications that require some Python packages).

Proposal for Further Changes

  • A brief discussion already happened at [2].
  • The SRPMs that produce binary RPMs for more Python runtimes should keep current names python-foo, the SRPMs that produce binary RPM for just one runtime should be named pythonX-foo.
  • All the binary RPMs must be named pythonX-foo, where X is the major version of the Python runtime that they use.
  • For the time being (and maybe forever), every python2-foo package must have Provides: python-foo.
  • This means that from user's perspective only one thing will change, and that is python-* packages will be renamed to python2-*, but will still keep the provide of python-*.

Why?

  • This concept will easily scale to more Python runtimes (PyPy, Jython), as already proposed previously by Tom Spur. Please note, that scaling to other runtimes is not part of this proposal and should be discussed further in another proposal/ML thread.
  • Currently, upstream recommendation [3] is to point /usr/bin/python to Python 2, but as the PEP notes, it will be reviewed and it is anticipated that in time it will be updated to recommend pointing /usr/bin/python to /usr/bin/python3. When this time comes, we should also move the provides suggested above (Provides: python-foo) from python2-* packages to python3-* packages to keep things like yum install /usr/bin/python python-foo consistent.
  • Having python2-* vs. python3-* packages is a good way of explicitly distinguishing packages from the two stacks. This is connected with the reason above - we should recommend using explicit usage of /usr/bin/python{2,3} and yum install python{2,3}-foo, and we should discourage use of implicit /usr/bin/python and python-* so that nothing breaks for users when these are changed in any way. (We already started to advertise usage of versioned /usr/bin/python{2,3} binary by deprecating %__python in current guidelines and recommending %__python{2,3}.)

Alternatives

  • Just keep what we have - doesn't seem to scale to other Python runtimes;
  • Only allow split SRPMs - too much maintenance work.

[1] https://fedoraproject.org/wiki/Changes/Python_3_as_Default [2] https://lists.fedoraproject.org/pipermail/devel/2013-July/186822.html [3] http://www.python.org/dev/peps/pep-0394/ [4] http://www.python.org/dev/peps/pep-0394/#future-changes-to-this-recommendation