manylinux

manylinux - это соглашение и набор готовых Docker-образов для сборки бинарных wheel'ов с C/Rust-расширениями для Python, которые устанавливаются и работают на большинстве дистрибутивов Linux. Wheel с расширениями на C или Rust компилируется под конкретную версию glibc и определённый набор системных библиотек; если наивно собрать его на рабочей машине, он может отказаться загружаться на чужой. manylinux существует для того, чтобы подход "один wheel для большинства Linux'ов" стал реальностью; по сути это серия PEP, определяющих, что именно значит "большинство Linux'ов", вместе с образами для сборки под эту базовую планку.

Как это устроено

Основная идея в том, что бинарник, собранный на одном дистрибутиве, работает на дистрибутивах того же возраста или новее, но не старше: wheel, слинкованный со свежей glibc, не загрузится там, где glibc старая. Поэтому manylinux собирает пакеты на намеренно старых базовых образах, и полученный wheel работает на всём начиная с этого поколения. Платформенный тег в имени wheel'а кодирует целевую базовую планку, а установщик (pip) проверяет этот тег на соответствие хосту перед установкой.

Эволюция платформенных тегов описана цепочкой PEP:

• PEP 513 - manylinux1 на базе CentOS 5
• PEP 571 - manylinux2010 на базе CentOS 6
• PEP 599 - manylinux2014 на базе CentOS 7
• PEP 600 - универсальная схема manylinux_x_y, привязанная напрямую к версии glibc (например, manylinux_2_28 означает glibc 2.28) вместо ввода нового именного тега под каждое поколение дистрибутивов
• PEP 656 - musllinux_x_y, та же идея с привязкой к musl для Alpine и других систем на musl

Образы публикуются в quay.io/pypa/... и тегируются так, чтобы сборка могла зафиксировать точный образ для воспроизводимости. Актуальный набор включает manylinux2014, manylinux_2_28 (AlmaLinux 8), manylinux_2_34 (AlmaLinux 9, альфа), manylinux_2_39 (AlmaLinux/Rocky 10, альфа и первый образ с поддержкой riscv64), manylinux_2_31 и manylinux_2_35 (armv7l), а также musllinux_1_2 (Alpine 3.22). Поддерживаемые архитектуры: x86_64, i686, aarch64, ppc64le, s390x, armv7l, riscv64. Образы на базе производных RHEL используют yum/dnf; образы для armv7l основаны на Debian и используют apt.

Использование

docker run --rm -v $(pwd):/io quay.io/pypa/manylinux_2_28_x86_64 \
  /io/build-wheels.sh
# inside: build with an old-glibc toolchain, then run auditwheel repair
auditwheel repair dist/mypkg-*.whl -w /io/wheelhouse/

auditwheel - сопутствующая утилита: она проверяет собранный wheel, убеждается, что он зависит только от библиотек из базового набора manylinux, и внедряет (graft) все дополнительные динамические библиотеки внутрь wheel'а, делая его самодостаточным.

Ограничения

• Самый острый подводный камень: RHEL 9 и его производные ориентируются на микроархитектуру x86-64-v2. Библиотеки, установленные через dnf в образе manylinux_2_28+, могут быть скомпилированы под v2 и встроены в wheel, который затем упадёт на старом x86_64-оборудовании, не поддерживающем v2. Ни один PEP не учитывает варианты микроархитектур, а auditwheel этого не замечает, поэтому wheel может пройти все проверки и всё равно упасть с ошибкой на старом процессоре.
• Образы со старой базой означают старый тулчейн. Сборка под manylinux2014 (CentOS 7) даёт компилятор и системные библиотеки той эпохи, если только не установить более свежие самостоятельно.
• Альфа-образы (manylinux_2_34, _2_39) пока не являются стабильными целями для сборки.

Это проявление стабильности ABI в мире упаковки wheel'ов: manylinux - ответ Python на привычку glibc ломать совместимость бинарников. Достигается это за счёт сборки на старых системах и бандлинга всего необходимого, подобно тому как вендоринг поставляет самодостаточные артефакты вместо доверия хосту. См. также win32-stable-abi с аргументом о том, что именно библиотека C является нестабильным слоем в Linux, и supply-chain-security о том, почему внедрение сторонних библиотек в wheel - это ещё и вопрос границы доверия.

Репозиторий

github.com/pypa/manylinux - Shell, MIT, ~1.76k звёзд.