This is similar to #1941, only that we're way earlier in the process. But like we had alma8 available while our default was still CentOS 6, we are in a situation where alma9-based infrastructure will be beneficial despite not being the default for a long time yet. Especially now with {{ stdlib("c") }} in place, this will be much less of a hassle.
The underlying RHEL 9.0 was released almost 2.5 years ago, and the first projects are starting to require newer glibc's than 2.28 (which itself is >6 years old). An indeed, based on https://mayeut.github.io/manylinux-timeline/ at least1, over 60% of PyPI downloads for clients on non-EOL python versions already have glibc >=2.34.
The manylinux project will release alma9-based images soon (c.f. pypa/manylinux#1585) and we should likewise be ready for whenever projects start requiring this.
This is similar to #1941, only that we're way earlier in the process. But like we had alma8 available while our default was still CentOS 6, we are in a situation where alma9-based infrastructure will be beneficial despite not being the default for a long time yet. Especially now with
{{ stdlib("c") }}in place, this will be much less of a hassle.The underlying RHEL 9.0 was released almost 2.5 years ago, and the first projects are starting to require newer glibc's than 2.28 (which itself is >6 years old). An indeed, based on https://mayeut.github.io/manylinux-timeline/ at least1, over 60% of PyPI downloads for clients on non-EOL python versions already have glibc >=2.34.
The manylinux project will release alma9-based images soon (c.f. pypa/manylinux#1585) and we should likewise be ready for whenever projects start requiring this.
cdt_name=condafor all distros cdt-builds#71Footnotes
I'd love to have an equivalent for conda-forge data... ↩