Hi folks,
Toshio pinged me about a problem with dnf using -OO in their shebang lines earlier today (https://bugzilla.redhat.com/show_bug.cgi?id=1230820), which got me thinking about our Python 3.5 adoption timeline (as I note in the issue there, the reason using -OO in system packages is currently a bad idea is a limitation in CPython's bytecode caching scheme that Brett Cannon has fixed for 3.5+).
The two relevant schedule docs are the ones for F23 and Python 3.5:
Fedora 23: https://fedoraproject.org/wiki/Releases/23/Schedule Python 3.5: https://www.python.org/dev/peps/pep-0478/
The upstream Python 3.5rc1 release is due on August 9, while the final release is due on September 13. To switch in F23 that would mean:
* getting a system-wide change for a Python 3 upgrade approved by the F23 deadline on Jun 26 * getting a 3.5 beta release incorporated by the testability deadline on July 28 (this would likely correspond to 3.5b3 upstream, which is due for release on July 5) * F23 Alpha would ship with a Python 3.5 beta release * F23 Beta would ship with a Python 3.5 release candidate * F23 final would ship with the Python 3.5.0 final release
Slavek's change proposal for the 3.4 upgrade in F21 is at https://fedoraproject.org/wiki/Changes/Python_3.4
Progress on the "Python 3 as default" effort means that the Py3 stack is significantly more critical now than it was back then. However, we also have better testing tools available.
In particular, for testing purposes prior to making the change in Koji, I'd suggest we consider Beaker's /distribution/rebuild task: https://beaker-project.org/docs/user-guide/beaker-provided-tasks.html#distri...
The example given there is for testing GCC changes, but it should work for this as well (while beaker.fedoraproject.org isn't open for more general access yet, I still have an account there from when I was working on the Beaker team, and worst case, we can do the test on Red Hat's Beaker internal instance instead).
The contingency plan if the Beaker rebuild showed significant problems that couldn't be resolved by the testability deadline would be to postpone the system-wide change to Fedora 24 (however, I'd consider issues of that magnitude to indicate an upstream compatibility problem, so it hopefully won't come to that)
If folks think this sounds like a plausible approach, I'd volunteer to work with Matej as Python 3 maintainer to push it forward.
Regards, Nick.
P.S. Miro's nightly SCLs at https://copr.fedoraproject.org/coprs/churchyard/python3-nightly/ may also have a part to play, although I'm not sure what that would be just yet
On 15.6.2015 02:49, Nick Coghlan wrote:
P.S. Miro's nightly SCLs at https://copr.fedoraproject.org/coprs/churchyard/python3-nightly/ may also have a part to play, although I'm not sure what that would be just yet
This should have helped us rebasing our patches and observing some test failures continually, so we don't get a storm of work when 3.5is ready for Fedora. However, for the lock of time, the builds of python in there are constantly failing and are basically unattended.
But getting it fixed might be the first step towards Python 3.5 in F23.
Hey Nick, sorry for the late response, I wanted to talk this through with the rest of the Python Maintainers to get their input as well. :)
----- Original Message -----
From: "Nick Coghlan" ncoghlan@gmail.com To: "Fedora Python SIG" python-devel@lists.fedoraproject.org Sent: Monday, June 15, 2015 2:49:45 AM Subject: Python 3.5 as a system-wide change for Fedora 23?
Hi folks,
Toshio pinged me about a problem with dnf using -OO in their shebang lines earlier today (https://bugzilla.redhat.com/show_bug.cgi?id=1230820), which got me thinking about our Python 3.5 adoption timeline (as I note in the issue there, the reason using -OO in system packages is currently a bad idea is a limitation in CPython's bytecode caching scheme that Brett Cannon has fixed for 3.5+).
The two relevant schedule docs are the ones for F23 and Python 3.5:
Fedora 23: https://fedoraproject.org/wiki/Releases/23/Schedule Python 3.5: https://www.python.org/dev/peps/pep-0478/
The upstream Python 3.5rc1 release is due on August 9, while the final release is due on September 13. To switch in F23 that would mean:
- getting a system-wide change for a Python 3 upgrade approved by the
F23 deadline on Jun 26
- getting a 3.5 beta release incorporated by the testability deadline
on July 28 (this would likely correspond to 3.5b3 upstream, which is due for release on July 5)
- F23 Alpha would ship with a Python 3.5 beta release
- F23 Beta would ship with a Python 3.5 release candidate
- F23 final would ship with the Python 3.5.0 final release
We feel that that's perhaps a little tight schedule, where things could go wrong easily. For that reason we'd like stay with Python 3.4 as system python for Fedora 23, while providing Python 3.5 in a Copr. (Perhaps using Miro's repo)
Does that make sense?
In any case, thank you for taking the time to write this, the Beaker note bellow is sure to be useful eventually. :)
Matt
Slavek's change proposal for the 3.4 upgrade in F21 is at https://fedoraproject.org/wiki/Changes/Python_3.4
Progress on the "Python 3 as default" effort means that the Py3 stack is significantly more critical now than it was back then. However, we also have better testing tools available.
In particular, for testing purposes prior to making the change in Koji, I'd suggest we consider Beaker's /distribution/rebuild task: https://beaker-project.org/docs/user-guide/beaker-provided-tasks.html#distri...
The example given there is for testing GCC changes, but it should work for this as well (while beaker.fedoraproject.org isn't open for more general access yet, I still have an account there from when I was working on the Beaker team, and worst case, we can do the test on Red Hat's Beaker internal instance instead).
The contingency plan if the Beaker rebuild showed significant problems that couldn't be resolved by the testability deadline would be to postpone the system-wide change to Fedora 24 (however, I'd consider issues of that magnitude to indicate an upstream compatibility problem, so it hopefully won't come to that)
If folks think this sounds like a plausible approach, I'd volunteer to work with Matej as Python 3 maintainer to push it forward.
Regards, Nick.
P.S. Miro's nightly SCLs at https://copr.fedoraproject.org/coprs/churchyard/python3-nightly/ may also have a part to play, although I'm not sure what that would be just yet
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
On 18 Jun 2015 10:02 pm, "Matej Stuchlik" mstuchli@redhat.com wrote:
We feel that that's perhaps a little tight schedule, where things could go wrong easily. For that reason we'd like stay with Python 3.4 as system python for Fedora 23, while providing Python 3.5 in a Copr. (Perhaps using Miro's repo)
Does that make sense?
It does. I also realised last night that there's a better, less disruptive path forward that relates to a discussion we had upstream at this year's language summit regarding the Python 3 transition and /usr/bin/python on POSIX systems: https://lwn.net/Articles/640296/
The idea I had in relation to that is to wonder whether we could come up with a self-contained change that allowed the normal python symlink to be swapped out for a configurable version switcher that was compatible with the distro independent environment module system now used for SCLs.
That approach would start us down the path of better separating the "system default Python" setting from the choice of "user's preferred Python", paving the way for users swapping in alternative implementations like PyPy and Jython, in addition to choosing between CPython 2.7, 3.4 & 3.5.
Cheers, Nick.
P.S. There's at least one current compatibility issue in the upstream Python test suite related to Fedora's upgrade to more secure default SSL settings: http://bugs.python.org/issue23965
python-devel@lists.fedoraproject.org
-
Matej Stuchlik -
Miro Hrončok -
Nick Coghlan