Python 2 deprecation plan and call for help

Message ID
DKIM signature
Download raw message
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

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):


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.


My goals are:

- Remove Python 2 support
- Normalize the package while we're at it
    - 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

I also recommend not having any Python packages installed in your build

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

- 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= & provides= 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="!check" and a comment
  explaining why
- The license is set to the correct upstream license and is a valid SPDX
- 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!

Drew DeVault