Manylinux 2 24

[mattip]

manylinux_2_24 let's build wheels for it

[rgommers]

I understand 2.24 is the glibc version (PEP 600), but where is the guidance on which wheels to build when?

[mattip]

Not clear where the question is directed. Is it

1. "what manylinux_2_x tag exists" or
2. "what machines can install a manylinux_2_4 wheel" or
3. "which platforms should prefer a manylinux_2_24 wheel over a manylinux2010 one"?

Right now the only PEP 600 wheel standard is manylinux_2_24, so the answer to (1) is "Only manylinux_2_24". Anyone whose platform can support it, and is using pip 20.3+, will be able to install the wheel (anywhere where this returns True), which is the answer to (2).

def supports manylinux_2_24():
    from packaging import tags
    platforms = {t.platform for t in tags.sys_tags()}
    return any(['manylinux_2_24' in p for p in platforms])

As for (3), we know for certain that ppc64le needs it to avoid the block-listed transcendental functions.

[rgommers]

Right now the only PEP 600 wheel standard is manylinux_2_24

This bit. The PEP doesn't specify 2_24, nor does it link to it. What defines this is the one standard that exists?

[mattip]

Basically this chart of glibc version versus disto EOL. Debian 9 is in LTS support and forms the base image for the manylinux_2_24 dockers. I think the motivation is to move forward but not past amazon2, however amazon2 as a base image is problematic.

[mattip]

Anyone can make a PR to pypa/manylinux with a different 2_xx proposal.

[rgommers]

Basically this chart of glibc version versus disto EOL. Debian 9 is in LTS support and forms the base image for the manylinux_2_24 dockers. I think the motivation is to move forward but not past amazon2, however amazon2 as a base image is problematic.

Impressive collection of information, but it doesn't say anything about what should be done.

Anyone can make a PR to pypa/manylinux with a different 2_xx proposal.

So I think your answer is: there's only a Docker image for 2_24 on that repo. There's nothing preventing anyone from uploading other 2_x flavors, and there aren't really and docs. And I guess Pip now understands all manylinux_x_y tags, but it probably doesn't know which ones it needs so it'll pick the most recent one (?).

[mattip]

it probably doesn't know which ones it needs so it'll pick the most recent one (?).

The order is defined by tags.sys_tags(), whatever matches first. For x86_64 on Ubuntu 20.04, with glibc=2.31, this is:

cp37-cp37m-manylinux_2_31_x86_64
cp37-cp37m-manylinux_2_30_x86_64
cp37-cp37m-manylinux_2_29_x86_64
cp37-cp37m-manylinux_2_28_x86_64
cp37-cp37m-manylinux_2_27_x86_64
cp37-cp37m-manylinux_2_26_x86_64
cp37-cp37m-manylinux_2_25_x86_64
cp37-cp37m-manylinux_2_24_x86_64
cp37-cp37m-manylinux_2_23_x86_64
cp37-cp37m-manylinux_2_22_x86_64
cp37-cp37m-manylinux_2_21_x86_64
cp37-cp37m-manylinux_2_20_x86_64
cp37-cp37m-manylinux_2_19_x86_64
cp37-cp37m-manylinux_2_18_x86_64
cp37-cp37m-manylinux_2_17_x86_64
cp37-cp37m-manylinux2014_x86_64
cp37-cp37m-manylinux_2_16_x86_64
cp37-cp37m-manylinux_2_15_x86_64
cp37-cp37m-manylinux_2_14_x86_64
cp37-cp37m-manylinux_2_13_x86_64
cp37-cp37m-manylinux_2_12_x86_64
cp37-cp37m-manylinux2010_x86_64
cp37-cp37m-manylinux_2_11_x86_64
cp37-cp37m-manylinux_2_10_x86_64
cp37-cp37m-manylinux_2_9_x86_64
cp37-cp37m-manylinux_2_8_x86_64
cp37-cp37m-manylinux_2_7_x86_64
cp37-cp37m-manylinux_2_6_x86_64
cp37-cp37m-manylinux_2_5_x86_64
cp37-cp37m-manylinux1_x86_64
cp37-cp37m-linux_x86_64
...

(repeats for cp37-abi3, cp37-none, cp36-abi3, ..., cp33-abi3, cp32-abi3, then py37-none, py3-none, py36-none, py35-none, ... py31-none, py30-none. After that there are the "any" plaform tags without manylinux* or linux_x86_64: py37-none-any, py3-none-any, py36-none-any, ... py31-none-any, py30-none-any`. All told 536 possible wheel names.

[mattip]

Adding all the glibc tags was pypa/packaging#293

[rgommers]

Nice, thanks for the info (and the hard work on that) @mattip.

[charris]

@mattip Should this be closed?

[mattip]

This will need pypa/manylinux#1012 which is about updating the gcc versions in the base image but leaving the libc++ version to be compatible with the older one. Basically, someone needs to port the changes RedHat does to the compilers when updating gcc for a RedHat version to the Debian image behind manylinux2_24