Собирали ли вы Python wheel файлы для Windows и Linux

Что проверяют

Понимаете ли вы, когда колесо вообще зависит от платформы. Если в пакете только код на Python, одно колесо с тегом py3-none-any ставится везде, и вопрос теряет смысл. Платформенная сборка начинается там, где есть скомпилированное расширение, и проверяют именно этот опыт.

Как отвечать

Скажите, что сборка описана в pyproject.toml и запускается фронтендом сборки:

python -m build

Дальше про теги. Имя файла содержит версию интерпретатора, ABI и платформу: cp312-cp312-win_amd64 или cp312-cp312-manylinux_2_28_x86_64. Значит колёс нужно столько, сколько комбинаций вы поддерживаете, и собирать каждое надо на своей системе или в контейнере.

Практика, которую ждут услышать:

• матрица в CI по операционным системам и версиям интерпретатора, либо cibuildwheel, который эту матрицу разворачивает сам;
• на Linux готовое колесо чинят через auditwheel: он затягивает нужные системные библиотеки внутрь и проставляет корректный тег manylinux, иначе пакет не встанет на чужом дистрибутиве;
• на Windows нужен компилятор MSVC, совместимый с версией интерпретатора;
• если расширение обходится ограниченным API, собирается одно колесо abi3 сразу на несколько версий, и матрица резко сокращается.

Закончите проверкой: ставим собранное колесо в чистое окружение и импортируем пакет, а не просто радуемся появившемуся файлу.

Где спотыкаются

Зовут python setup.py bdist_wheel. Это устаревший путь, современный интерфейс сборки не требует запускать setup.py руками.

Второе: считают, что колесо упаковывает зависимости. Оно их только объявляет, а системные библиотеки не тянет вовсе, ради этого и существует этап починки колеса.

Третье: собирают на своей свежей системе и удивляются отказу установки. Колесо, слинкованное с новой системной библиотекой C, не встанет на машину постарше, поэтому сборку ведут в контейнере с заведомо старым базовым окружением.