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= & 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
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!
--
Drew DeVault