Received: from mail.cmpwn.com (mail.cmpwn.com [45.56.77.53]) by nld3-dev1.alpinelinux.org (Postfix) with ESMTPS id F121E782CFE for <~alpine/devel@lists.alpinelinux.org>; Thu, 18 Jul 2019 00:51:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cmpwn.com; s=cmpwn; t=1563411070; bh=A7uXemGjVSl3l6y4PVLh50Sv6sC/Zi/u6Abf3Ms350s=; h=To:From:Date:Subject; b=EjjyFziz2PiGQ7wWxPPZicixCPhCbDy3+QV/L/z78FU9BUSkuDi3oP+ieHPg8tH/K 0roUI3ogCnfYEIbeO3rUTaT7KSKxqhpzTQjmR/gmpOWEtQJHx0VR6L61H78IEcDuzv FZDMaakWD501iuY8fd2PR97k9hK97TUbT14+u20s= Content-Transfer-Encoding: quoted-printable To: <~alpine/devel@lists.alpinelinux.org> From: "Drew DeVault" Date: Wed, 17 Jul 2019 20:51:09 -0400 Subject: Python 2 deprecation plan and call for help Message-Id: Content-Type: text/plain; charset=UTF-8 Hiya! I know this is a long email, but bear with me - reading it pales in comparison to the sisyphean task ahead of us. Earlier today I sent the first round of patches for dropping Python 2 support from Alpine Linux to aports. I've started with testing, then plan to move on to community, and finally main. Not including the 40 packages I've already done, the total number of packages to address are: testing 234 community 126 main 142 502 total This is just packages which match py-* or py2-*, but there are other packages which depend on python2 as well (will sort them out later, or as they come up). On average it's taken me about 5 minutes per package, so we're looking at about two days of consecutive work. I would very much appreciate some help sharing this burden. If you'd like to work on this, please shoot me an email (or ping ddevault on IRC) sharing how much time you can spend on this and I'll assign you some packages. I'm doing them alphabetically, so I'll assign you a range of letters and try to avoid having multiple people doing the same work. Send me your public key too and I'll give you push access to the git repo where I'm staging this work (testing-drop-py2 branch): https://git.sr.ht/~sircmpwn/aports We have 5 months and 14 days before Python 2 is end-of-life, which lines up pretty nicely with the Alpine 3.11 release. https://pythonclock.org/ My goals are: - Remove Python 2 support - Normalize the package while we're at it https://wiki.alpinelinux.org/wiki/Python_package_policies - I have `:set list` on in Vim so I can check that they use tabs instead of spaces - Remove `|| exit 1` and such - I've been adding check() functions to every package when upstream provides a test suite - Read the build output and see if it's downloading any PyPI packages during the build - if so, add them to the dependencies and make a new APKBUILD if necessary - Drop python3-dev and try to build without it first - then re-add it if the package fails due to missing Python.h - Update to the latest upstream version - Drop any packages which are unmaintained upstream, or which exist specifically to provide support for py2 programs (e.g. py2-enum34) - Review any dependent packages for cases which need special consideration I also recommend not having any Python packages installed in your build environment. My workflow involves taking a list of packages I want to work on, putting them in a text file under "todo", and under "doing" move each package I'm working on. If I find other affected packages (e.g. dependencies which explicitly depend on py2-*), I add them to my todo list. I move packages to a done list when they're finished, but I periodically discover new problems with them and add notes to them to address later. I also have a checklist which I use to make sure each package was done right: - The package name is py3-example and _pyname is set to the PyPI name - The source URL is from PyPI using the boilerplate from the wiki - replaces=3D & provides=3D are set correctly if appropriate - Either the pkgver has been updated to the newest upstream version, or pkgrel has been bumped - A check() function has been added, or options=3D"!check" and a comment explaining why - The license is set to the correct upstream license and is a valid SPDX identifier - The commit message is something like this: $repo/$pkgname: normalize, drop py2 $repo/$pkgname: normalize, upgrade, drop py2 $repo/$pkgname: remove unmaintained package [explanation in the extended commit message] I'm also keeping a list of special cases which require further discussion. Examples of these cases are: - An upstream shows no signs of supporting py3, but is important and/or depended on by important stuff - An upstream is working on Python 3 support and is likely to have it done before EoL - An upstream is working on Python 3 support but probably won't have it done before EoL Let me know as soon as possible if you have any objections to this plan, since we'll be investing a lot of work into it. Please help! --=20 Drew DeVault