Heads-Up: dropping CPython 2.7 in manylinux2010

[mayeut]

It's about time to drop support for CPython 2.7 !

manylinux will soon merge the manylinux2014 branch in master which is used to build manylinux2010. There will now be a single branch / source of truth for what tools are installed in manylinux images with newer PEP600 images on the way.

Rather than adding CPython 2.7 to manylinux2014, it will be dropped from manylinux2010 once the merge happens.

If cibuildwheel wants to keep supporting CPython 2.7, we'll have to add specific pinned images for this use-case in cibuildwheel.

c.f. pypa/manylinux#428 (comment)

PS: manylinux1 is not affected by this rewrite but support for manylinux1 will probably be dropped by the summer.

[henryiii]

Nice site! (https://mayeut.github.io/manylinux-timeline/ ). Tiny note, your colors cycle, so the final four items on the Python versions have the same colors as the initial ones. MPL has a 9 or 10 color cycler by default, I think.

[mayeut]

Tiny note, your colors cycle, so the final four items on the Python versions have the same colors as the initial ones. MPL has a 9 or 10 color cycler by default, I think.

I know, I've been too lazy to update this. I think I remember those were the ones automatically chose by plotly and I saw that but didn't update.

[henryiii]

That still looks like it's over 60% manylinux1, though? I've noticed at least NumPy is basing manylinux support by Python version. The 3.9 wheel comes in manylinux2010 only, while 3.7 and 3.8 still come in manylinux1. So manylinux2010 dropping 2.7 might just complicate things for a while, when it is still legal to build 2.7 + manylinux1. Once manylinux1 support drops, then cibuildwheel can drop 2.7 too, I'd think. Again, we work a lot harder to support 3.5 than 2.7, the "LTS" like-releases helped 2.7.

[mayeut]

Well, it's hard to know where exactly is the cursor for manylinux1. It's somewhere between 35% and 55%. Other than going over all projects manually, there's no way to tell if they built on manylinux2010 or manylinux2014 but still got manylinux1 compatibility (this is the case for my project which is really simple) or if they have multiple builds like is the case for NumPy.
I thought that NumPy made this choice based on the pip version available when 3.7, 3.8 & 3.9 got released but that does not seem consistent for 3.8, maybe @mattip has an idea ?
Although >99.9% manylinux systems downloading wheels are theoretically manylinux2010 compatible, pip might be too old to know about this. c.f. pypa/manylinux#542 (comment)

[henryiii]

I do believe it's almost purely pip and/or simply only providing manylinux1; in HEP we do have Scientific Linux 6 in use, but that should support manylinux2010 (just not 2014). But it comes with pip 7, IIRC. Pip 9 is common on CentOS 7, which is what we've replaced most of the 6's with. With 8 being killed off in favor of CentOS 8 Stream, I could see CentOS 7 sticking around till 2024... :'(

[henryiii]

When will 3.5 be dropped?

[henryiii]

Honestly, we have more workarounds for 3.5 than 2.7, since maintenance ended for that sooner than 2.7.

[mayeut]

I think 3.5 will drop after ubuntu 16.04 EOL, once python 3.10 beta lands. So probably around May, we'll drop CPython 3.5 and add CPython 3.10.

[mattip]

I want to drop manylinux1 for NumPy's next release (summer 2021). When NumPy does that, the other scientific python libraries will probably follow.

Pip 9 is common on CentOS 7, which is what we've replaced most of the 6's with

This is unfortunate. Is that true even for python 3.7+ ?

[mayeut]

Pip 9 is common on CentOS 7, which is what we've replaced most of the 6's with

This is unfortunate. Is that true even for python 3.7+ ?

No, that's only true for the default pythons which are 2.7 & 3.6.
If you want something >= 3.7 on CentOS 7 and just want to yum install it, then there's python 3.8 from sclo which come with pip 19.3.1:

rh-python38-python-pip-19.3.1-1.el7.noarch : A tool for installing and managing Python packages
Repo        : centos-sclo-rh
Matched from:
Filename    : /opt/rh/rh-python38/root/usr/bin/pip3

[henryiii]

• 20.3 was the first version to support 3.9
• 19.1 or so was when 3.8 officially was supported
• 18.1 was the first version to support 3.7

Before that, it's not documented, but roughly 9 for 3.6, I expect, and I see a bug for 3.5 fixed in the 7 series. So by dropping support for 3.6, you should not have any users stuck without the ability to use manylinux2010.

Edit: Oops, I though 2010 was added before 19. So there might be 18.x users. I don't think there are too many people stuck on 18, though - 9 was rather special, since 10 broke the pip script installed into sudo locations on many platforms. For 3.8+, this is true.

[henryiii]

Actually, a much better is to check the versions shipped by default: pypa/build#226 (comment)

So 3.7.0 technically shipped with 10.

[mattip]

The problem is that manylinux1 is based on a very old CentOS. So while dropping manylinux1 may cause some pain, it is going to happen this year.

[henryiii]

I'm not worried¹ about that, I just think cibuildwheel should match manylinux support. As soon as it's dropped, we should drop it too, basically.

Footnotes

1. I'm not worried about that here. ;) ↩

[mattip]

The problem with dropping manylinux1 is that pip will prefer to install-from-source than to use an older binary version by default. There is the --only-binary :all: flag, I wonder if we could teach CentOS7 to use that by default. Otherwise there will be many unhappy people who do pip install and end up compiling the world.

[Czaki]

The problem with dropping manylinux1 is that pip will prefer to install-from-source than to use an older binary version by default. There is the --only-binary :all: flag, I wonder if we could teach CentOS7 to use that by default. Otherwise there will be many unhappy people who do pip install and end up compiling the world.

Could You explain or point documentation? I see no problem with installing a mix of manylinux1, manylinux2010, and manylinux2014 packages. Or you think about only manylinux images?

[mattip]

Say I have pip 9, that does not know about manylinux2010. When I do pip install numpy, it will see version 1.21 has a source tarball, but will not see the manylinux2010 binary wheels. Version 1.20 has a manylinux1 wheel, so theoretically pip could install that, but it will prefer the 1.21 source tarball over the 1.20 binary wheel. In order to convince this version of pip to install the 1.20 binary wheel, I need to do pip install --only-binary numpy numpy

[mayeut]

@Czaki,
to extend @mattip example, here's an excerpt from manylinux README, there's a minimal requirement on pip version to be able to install manylinux* wheels. pip will fail to "see" them on PyPI with versions less than the one listed here.
PEP600 is not yet in the readme and requires pip >= 20.3.

manylinux tag	Client-side pip version required
manylinux2014	pip >= 19.3
manylinux2010	pip >= 19.0
manylinux1	pip >= 8.1.0

[Czaki]

Ahh. "Upgrade pip first" problem...
And mixing system python (outdated one) with working environment.

[mattip]

No, that's only true for the default pythons which are 2.7 & 3.6.

Binary wheels for scientific python (NumPy, SciPy, ...) will not be shipped in 2021 for python<=3.7 anyway, so I think it is fine to deprecate manylinux1.

[joerick]

My feeling is that now we're over a year after EOL, we should consider dropping CPython 2.7 altogether, soon. We can still point in docs to our final release that supports it, and users that really need it could run twice, like:

CIBW_BUILD=cp27* pipx run cibuildwheel==1.9.0
pipx run cibuildwheel==2.0.0

I suppose, in theory, we could accept bugfix PRs to a 1.9.x branch, if there's still a strong need when/if that breaks too.

Thoughts?

[Czaki]

Some packages still release fake manylinux1 packages (like PySide2)

[henryiii]

I do too. ;)

[henryiii]

Though, in my case, it's only "fake" due to compiling a new compiler for it, as GCC 4.8 didn't support C++14.

[Czaki]

Qt in the new versions needs a newer version of glibc than could be assumed with manylinux1 tag.

[YannickJadoul]

Though, in my case, it's only "fake" due to compiling a new compiler for it, as GCC 4.8 didn't support C++14.

I cough cough cough used to just statically link libstdc++, actually, to solve that issue (see pypa/manylinux#118). Then decided it's not worth it and manylinux2010 was a lot more relaxing.