matrix of manylinux images for one Python

[minrk]

Is it possible/easy to build with multiple manylinux images? I have a project (pyzmq) where there are some benefits to targeting more recent glibc (2.28). I've conservatively only done this for CPython 3.11, but I've already received reports about folks not getting their expected wheels for CPython 3.11 with CentOS 7 and I haven't even made a release yet (I have published a beta).

So I'd like to take the easiest approach to publishing both 2014 and 2_28 wheels.

There doesn't appear to be an easy way to have a matrix of manylinux images in my cibuildwheel config via pyproject, which means I guess I need to do this at the matrix level in my CI itself?

Are there any CI examples of folks publishing multiple manylinux builds for a single Python target? How is this likely to interact with my overrides config in pyproject.toml?

[joerick]

Yeah, you'd have to do this with multiple invocations of cibuildwheel, customising the CIBW_MANYLINUX_*_IMAGE env var each time. Most people don't bother because manylinux is supposed to be forward-compatible.

BTW, most issues with manylinux tags are resolved by updating pip - often pip is too old and doesn't recognize the new tag, even though it's compatible. Worth trying that too, before going through the faff.

[minrk]

I think it's not the pip version, it's actually the glibc version, since users are facing this with Python 3.11. It's not the tag support that's the problem, it's the actual runtime support, correctly expressed by the new tags. I'll double check, though.

[henryiii]

I used to do this here - there's a vanilla manylinux2010 build and a custom manylinux1 build: https://github.com/scikit-hep/boost-histogram/blob/5f89f9237c3d030851716636c282724cfa517ab1/.github/workflows/wheels.yml#L89-L111

(Now that I've dropped 3.6, it's not really needed anymore)

[henryiii]

I'd also strongly suggest thinking about per-Python selection of manylinux (via overloads). NumPy, for example, picks 2010 vs. 2014 based on Python version. Newer Python's aren't running older pips (usually, minus some distro packaging hacks).

[minrk]

I'd also strongly suggest thinking about per-Python selection of manylinux (via overloads).

That's exactly what I'm doing and unfortunately the source of the problem. I only used the newer glibc for 3.11, but apparently folks are running 3.11 with very old glibc (in CI, at least), so I wanted to see the lightest way to add an older glibc build as a fallback for a single Python.