The first beta for Python 3.7 is out. It will hopefully get into Fedora
soon as python37.
After it comes out of beta, we'll upgrade python3 to it.
The What's New list is at: https://docs.python.org/3.7/whatsnew/3.7.html
One thing that's interesting for packagers is PEP 552: Deterministic
Let me summarize in my own words.
A new opt-in mode for byte-compilation makes .pyc (bytecode cache) files
depend only on the contents of the corresponding source file.
If we use this, it will slow down imports, because the whole source file
would need to be read and hashed in order to verify if a .pyc file is
valid. (Currently, metadata like the modification time and file size is
To speed things up, there's an option, UNCHECKED_HASH, which skips cache
validation entirely. Using this would mean that if you modify a .py
source file installed by RPM, the changes wouldn't take effect (the .py
contents would only be shown in tracebacks).
Modifying installed files in production is extremely bad practice, of
course, but it's quite useful for debugging on throw-away systems. If we
adopt UNCHECKED_HASH, anyone doing it will have to remember to remove
the corresponding .pyc file.
Honestly, I'm not sure we want to use this in Fedora. Is anyone here
into reproducible builds, to make a better argument for this?
During the 3.7 boostrapping of the interstitial sequence of Python 3
packages, I have noticed it includes a lot of packages that are only
intended as Python 3 stdlib backports for older Pythons.
https://pypi.org/project/contextlib2/ is a backport of the standard
library’s contextlib module to earlier Python versions
https://pypi.org/project/linecache2/ is a backport of linecache to older
https://pypi.org/project/pathlib2/ The goal of pathlib2 is to provide a
backport of standard pathlib module which tracks the standard library
module, so all the newest features of the standard pathlib can be used
also on older Python versions.
https://pypi.org/project/traceback2/ is a backport of traceback to older
https://pypi.org/project/unittest2/ is a backport of the new features
added to the unittest testing framework in Python 2.7 and onwards.
https://pypi.org/project/simplejson/ is the externally maintained
development version of the json library included with Python 2.6 and
Python 3.0, but maintains backwards compatibility with Python 2.5.
https://pypi.org/project/funcsigs/ is a backport of the PEP 362 function
signature features from Python 3.3
https://pypi.org/project/mock/ is now part of the Python standard
library, available as unittest.mock in Python 3.3 onwards.
Now I see fairly no real reason to have python3-contextlib2,
python3-linecache2 etc. packaged and maintained in Fedora. The only
reason there is that other packages actually depend on them.
I think we should actively change the packages not to depend on those
and eventually get rid of them. This involves changing how upstreams are
using those. Thoughts?
Here is some dependency info:
$ whatrequires python3-contextlib2
$ whatrequires python3-linecache2
$ whatrequires python3-pathlib2
$ whatrequires python3-traceback2
$ whatrequires python3-unittest2
$ whatrequires python3-simplejson
$ whatrequires python3-funcsigs
$ whatrequires python3-mock
...320 source packages buildrequire this one!
The Python 3.7 rebuild in the f29-python side tag is currently:
- 2168 built
- ~170 FTBFS
- ~120 blocked by dependencies that FTBFS
Ideally, this would all get fixed before the merge, but that's
unrealistic, there are packages that are FTBFS for unrelated reasons, etc.
What is the criterion to merge the side tag?
The critpath installs fine (except stuff that cannot be installed due to
yum-deprecated vs yum collisions and gnome-software that has some broken
dependency on PackageKit).
Stuff that doesn't build and sounds important:
- ceph (also FTBFS in regular rawhide)
- libreoffice (also FTBFS in regular rawhide)
- orca (blocked by pyatspi, looking at it ATM)
I've just started to build the bootstrap sequence in a side tag
This should not affect you mostly but if you have a Python 3 package and
you are going to update it with new buildtime dependencies, please let
me know or wait until this is done.
The initial order is in
On 21.6.2018 06:12, Jerry James wrote:
> On Wed, Jun 20, 2018 at 1:36 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>> Unfortunately this is blocked by failing:
> I had planned to look at that tonight. However, just as I arrived
> home from work tonight, as I was pulling into my driveway, my
> neighbor's propane grill exploded, catching his deck and then his
> house on fire. Fortunately there were no serious injuries.
I'm glad nobody go seriously hurt.
> Is there a way to do a mock build against the packages currently in f29-python?
fedpkg mock-config --target f29-python
This gives you a mock config you can use with mock -r or fedpkg
mockbuild --root. (Untested.)
On 5.6.2018 18:21, Jerry James wrote:
> On Tue, Jun 5, 2018 at 9:30 AM, Miro Hrončok <mhroncok(a)redhat.com
> <mailto:email@example.com>> wrote:
> On 11.5.2018 17:54, Miro Hrončok wrote:
> python2-notebook is a leaf package (nothing in Fedora
> (build)requires it). I'd like to drop it from rawhide. Any
> Uh oh. I just added both a BR and an R from sagemath to
> python2-notebook a couple of days ago, because sagemath does require
Does it require all of it? It's not a library. Can we see what exactly
is required and why maybe? How is it used - via Python imports or via
the command form /usr/bin?
> Can we bring it back? I can help maintain it if maintenance cycles
> are an issue.
We can, but please check the above first.
The issue is that upstream no longer seem to care about Python 2. Last
time, it had some SyntaxErrors on legacy Python. Fortunatelly, only in
some tests, so I've dropped those from the py2 package, but I just
didn't want to deal with this any more.
python2-notebook is a leaf package (nothing in Fedora (build)requires
it). I'd like to drop it from rawhide. Any objections?
This **does not** affect the ability to run Jupyter Notebook (via the
jupyter-notebook command) with Python 2 kernel (from the