python-devel May 2018

python-devel@lists.fedoraproject.org

8 participants
8 discussions

Python 3.7's Deterministic pycs
by Petr Viktorin 15 Jul '19

15 Jul '19

Hello! 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 pycs: https://www.python.org/dev/peps/pep-0552/ 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 used.) 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? -- Petr Viktorin

5 5

Intent to drop python2-notebook
by Miro Hrončok 05 Jun '18

05 Jun '18

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 python2-ipykernel package). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 1

Python 3.7 status in Fedora
by Miro Hrončok 30 May '18

30 May '18

Hi, this is just a summary about what is currently happening with Python 3.7 in Fedora [0]. Upstream has delayed the first RC a bit [1]. So we are not pushing anything to rawhide just yet. However I'm working on a "topsort rebuild" in Copr [2] on 3.7.0b3 to see what order [3] we'll need once this goes to rawhide. I'm currently trying to approach a state where the following packages are successfully built: * dnf * cloud-init * anaconda * abrt * python-flask * python-django * koji * bodhi * fedpkg * dnf-plugins-core (Anything else that should be on the list? Note that sphinx, pytest etc, is included as a dependency, I'm mostly trying to build apps.) Several packages are blocking this effort, all have open bugs at [4], if you'd like some upstream involvement, go ahead and look at some, I won't be able to fix them all alone :) [0] https://fedoraproject.org/wiki/Changes/Python3.7 [1] https://www.python.org/dev/peps/pep-0537/#schedule [2] https://copr.fedorainfracloud.org/coprs/g/python/python3.7/builds/ [3] https://github.com/hroncok/rpm-list-builder/blob/python37/python37.yaml [4] http://bugzilla.redhat.com/show_bug.cgi?id=PYTHON37 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

3 4

removal of python2-firewall
by Martin Bukatovic 28 May '18

28 May '18

Dear python devel, I just noticed that since Fedora 28, package python2-firewall is no longer available and while I know that python2 packages nobody seems to rely on are being gradually removed nowadays, I wonder why exactly was this particular package removed. The problem here is that without python2 module for firewalld, one can't use an ansible playbook to reconfigure firewall on Fedora machine: https://bugzilla.redhat.com/show_bug.cgi?id=1575428 And while switching to python3[2] may solve this particular problem, I don't think it's a reasonable solution from Fedora perspective, which: * packages Ansible so that it runs on python 2 * provides Firewalld to manage firewall by default Decision to drop python2-firewall then looks little weird, as it breaks the general expectation that ansible playbook using firewalld module is able to reconfigure firewall on a fedora machine. Moreover other python2 modules which some ansible modules are using such as python2-libselinux or python2-dnf are still available, and dropping python2-firewall doesn't look very consistent. That said, these python2 subpackages will not be installed by default[3]. The other problem here is that it's not easy to spot such problem, as this kind of dependency is not visible via rpm requirements (see eg. BZ 1505082 for explanation :). Maintainer dropping his python2 subpackage could very easily miss this. What do you think? Do we want to continue dropping python2 modules and encourage people to reconfigure ansible to run under python 3 while shipping ansible with python 2 or do we want to keep python2 modules used by ansible available, even thouhg this is not easy to track right now? And don't get me wrong, I'm a fan of switching to python3 and I agree that helping ansible guys with python 3 testing and porting is good for Fedora. I just don't think that dropping random packages from distribution so that random modules doesn't work with default ansible is a good way to do it. [1] https://src.fedoraproject.org/rpms/firewalld/c/40f23213c95db820a0d725e42a6d… [2] http://docs.ansible.com/ansible/latest/reference_appendices/python_3_suppor… [3] https://fedoramagazine.org/getting-ansible-working-fedora-23/ -- Martin Bukatovic

3 4

Are 3.6.x release candidates useful to find bugs?
by Petr Viktorin 22 May '18

22 May '18

Hello! At PyCon US 2018, Łukasz Langa, the release manager for Python 3.7, told me that he'd like to collect data about Release Candidates for point releases (3.x.y). The idea is that if these aren't being tested and aren't revealing bugs, it would make sense to stop releasing them. So, please, if you find any bugs in upcoming Python *3.6.x* release candidates, let me know (or write to Łukasz directly)! If there are no such reports, there will be no 3.7.x RCs. Also, are these useful for Fedora? Do/should we test 3.x.y RCs? (3.x.0 pre-releases like the current 3.7.0 beta are a different matter; those are obviously useful.)

4 4

Intent to retire python33
by Miro Hrončok 15 May '18

15 May '18

Hi, I'd like to retire python33 from Fedora 29+. Upstream has ended 3.3 support in September 2017 [1]. It was security only since October 2014. Red Hat does not support 3.3 in any of the products (AFAIK). Software collection python33 is EOL since Oct 2016 [2]. Python 3.3 was somehow important with OpenShift Online 2, because that was the only out of the box working Python 3. OpenShift Online 2 is EOL since December 2017 [3]. Debian jessie (oldstable) has Python 3.4. Debian wheezy (oldoldstable) has 3.2 so that one is irrelevant anyway (regardless being oldold). Ubuntu 14.04 LTS has 3.4. Ubuntu 12.04 LTS has EOLed in August 2017 and had 3.2 anyway. I see no reason a developer would need to test their code against Python 3.3 in 2018. However I might be missing something. If nobody speaks up, I'll retire python33 in 1-2 weeks. [1] https://www.python.org/dev/peps/pep-0398/ [2] https://www.softwarecollections.org/en/scls/rhscl/python33/ [3] https://blog.openshift.com/migrate-to-v3-v2-eol/ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 1

Removing python2-tox (second attempt)
by Miro Hrončok 15 May '18

15 May '18

Hi all, quite recently I've managed to remove the last thing that required python2-tox: python-detox was switched to Python 3 [1]. So I went ahead and removed python2-tox [2]. However, I forgot to check buildrequires. I do apologize for that overlook, apparently a couple of packages buildrequire python2-tox and people were (rightfully) surprised by python2-tox being removed without any notice [3]. So I added it back in [4]. Now I try to communicate this better. "tox" the command is in python3-tox since Fedora 25. python2-tox only offers the Python module to import from Python 2 (a very unlikely thing to happen). If you need to run the tox command during a package build, either buildrequire %{_bindir}/tox or just tox. I went ahead and sent PRs for all the packages that buildrequired python2-tox for historical reasons. List is on the end of this e-mail. Several of them don't use tox at all. (Note that the only package that actually needed python2 tox module was python-mpd2, utilizing the upstream discouraged tox invocation trough setup.py [5]. It now uses tox directly (in the PR).) I see no point of offering the tox module to import and I would like to get rid of it. I'll merge the PRs in ~1 week and then I'll remove python2-tox once again. Please let me know if you think this is breaking anything. Thank you and sorry for the mess. [1] https://src.fedoraproject.org/rpms/python-detox/pull-request/2 [2] https://src.fedoraproject.org/rpms/python-tox/pull-request/1 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1575667 [4] https://src.fedoraproject.org/rpms/python-tox/pull-request/2 [5] http://tox.readthedocs.io/en/latest/example/basic.html#integration-with-set… Pull requests: https://src.fedoraproject.org/rpms/ceph-deploy/pull-request/2 https://src.fedoraproject.org/rpms/custodia/pull-request/2 https://src.fedoraproject.org/rpms/pyee/pull-request/1 https://src.fedoraproject.org/rpms/python-atomicwrites/pull-request/2 https://src.fedoraproject.org/rpms/python-dpkt/pull-request/2 https://src.fedoraproject.org/rpms/python-f5-icontrol-rest/pull-request/2 https://src.fedoraproject.org/rpms/python-gssapi/pull-request/2 https://src.fedoraproject.org/rpms/python-icalendar/pull-request/2 https://src.fedoraproject.org/rpms/python-mpd2/pull-request/1 https://src.fedoraproject.org/rpms/python-oauth2client/pull-request/1 https://src.fedoraproject.org/rpms/python-parsedatetime/pull-request/3 https://src.fedoraproject.org/rpms/python-pyuv/pull-request/2 https://src.fedoraproject.org/rpms/python-terminaltables/pull-request/2 https://src.fedoraproject.org/rpms/python-txaio/pull-request/2 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 1

Python Environment
by José Abílio Matos 01 May '18

01 May '18

Probably some, or most, of you have already seen this but I find Randall Munroe's cartoon right on the point (for most issues and this about python is not an exception): https://xkcd.com/1987/ Regards, -- José Abílio

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel May 2018