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#distr…
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(a)gmail.com | Brisbane, Australia
Dear python-devel list,
I have few questions about the Packaging:Python wikipage[1],
with hope that this list is the right one for me to do so.
The page doesn't discuss much any differences in guidelines
for packages of python modules, python applications and
when python project provides both. For example both ruby
and haskell packaging guidelines covers this topic. Would you
consider this to be important/useful enough for new packager
to provide better guidance?
There is no mention of any semi automatic tools which would
try to create initial spec file based on metadata provided
in PyPI. Like bdist_rpm of distutils or py2pack. Do you use
them to create initial spec file? Is there any official
policy on this? Is there any reason not to use such tools?
Moreover would you think that listing few nicely packaged
python projects on the wikipage would make sense?
Besides that I puzzled about few other details which
involves "python 3 as default" requirements, but this I
leave out for now.
[1] https://fedoraproject.org/wiki/Packaging:Python
Thank you for your answer
Martin Bukatovic
