cibuildwheel: делаем колеса в промышленных масштабах

Ссылка: https://github.com/pypa/cibuildwheel

Привет! Вы наверняка когда-нибудь задумывались, откуда берутся все те замечательные wheel пакеты под разные системы и архитектуры для наших любимых зависимостей с бинарными частями. Например: mypy, black, тд.

Вот и я - нет!

Но, когда мне для релиза django-modern-rest@0.5.0 потребовалось компилировать части фреймворка с mypyc для получения перформанса на ровном месте - мне пришлось разобраться. Так давайте и вам расскажу.

Как оно работает?

Пакет - достаточно простой, обычная клиха (украл слово у @diementros). При запуске - указываем какой wheel нужно собрать. Например:

cibuildwheel --only cp313-macosx_arm64 --config-file pyproject.toml

Соберет вам текущий пакет для 3.13 и macos с arm64 архитектурой. А вот конфигурация:

[tool.cibuildwheel]
build = "cp3{11,12,13,14}-*"
build-frontend = "uv"
test-command = 'your_test_command'

Как будет проходить сборка? Полный лог: https://github.com/wemake-services/django-modern-rest/actions/runs/24023507014/job/70057082696#step:4:195

1. Сначала устанавливается нужный питон из готовых образов
2. Подготавливаем окружение
3. Запускаем build систему. Она берется из вашего pyproject.toml / setup.py

Например, у нас она выглядит так (мы используем uv, у которого нет родной билд системы для бинарных зависимостей, потому используем `hatch`):

[build-system]
requires = ["hatchling", "hatch", "hatch-fancy-pypi-readme"]
build-backend = "hatchling.build"

Вторая часть задачи: запустить сам mypyc на нужных файлах. К hatch есть плагинчик hatch-mypy. Его надо тоже настроить:

[tool.hatch.build.targets.wheel.hooks.mypyc]
enable-by-default = false
dependencies = ["hatch-mypyc", "mypy==1.19.1"]
include = ["dmr/_compiled"]
require-runtime-dependencies = true

Тут мы указываем: что билдим, что по-умолчанию билд с mypyc выключен, какие зависимости для билда нужны и что нужно поставить рантайм зависимости для билда. Билдить с mypyc будем только если есть специальный флаг:

[tool.cibuildwheel.environment]
HATCH_BUILD_HOOKS_ENABLE = "1"

Только когда он есть (или мы билдим с cibuildwheel), то сборка пакета запустится. Такое нужно нам, чтобы иметь возможность делать нативные python-only сборки без .so частей.

4. Запускаем тесты собранного wheel пакета с test-command, проверяем, что собранный пакет работает
5. Замеряем, что наши скомпилированные части реально стали работать быстрее

Готово!

Запускаем в CI

Последняя часть: нужно как-то запустить CI с 50+ разных вариантов конфигураций. cibuildwheel тут снова поможет. Он умеет выплевывать такие конфигурации для CI командой: CIBW_BUILD="cp313-*" cibuildwheel --print-build-identifiers --platform macos.

Далее дело техники, собираем матрицу всех задач для нужной CI и запускаем такую матрицу:

  mypyc:
    name: mypyc wheels ${{ matrix.only }}
    needs: configure
    runs-on: ${{ matrix.os }}
    strategy:
      fail-fast: false
      matrix:
        include: ${{ fromJson(needs.configure.outputs.include) }}

Самая хитрая часть тут в include: там мы как раз динамически подставляем конфигурации от cibuildwheel.
Получается удобно и довольно просто.

Последним шагом мы просто загружаем данные пакеты при release, используя PyPI Trusted Publisher.

И вот так - к вам приехал новый релиз django-modern-rest с опциональными бинарными частями для СКОРОСТИ: https://github.com/wemake-services/django-modern-rest/releases/tag/0.5.0

Анонс митапа в Нижнем

Кстати, у нас скоро будет PythoNN митап в Нижнем Новгороде со всеми вашими любимыми спикерами: @diementros @pymineral, а еще Роман Фролов и Михаил Васильев.

17 апреля, начало в 18:30.
Регистрация: https://pytho-nn.timepad.ru/event/3880099

Приезжайте, приходите. Будет много пива, настолок, разговоров про питон.

Обсуждение: чем вы билдите колеса на работе? Нужно ли вообще такое где-то, кроме опенсорса?

| Поддержать | YouTube | GitHub | Чат |