В этом практикуме упакуем httpie — удобный CLI-клиент для HTTP-запросов, написанный на Python. Это отличный пример для изучения упаковки Python-приложений, потому что httpie использует современный формат pyproject.toml, устанавливает CLI-скрипты и зависит от множества Python-библиотек.

Что вы узнаете

• Как использовать %pyproject_* макросы для сборки Python-пакетов
• Что такое BuildArch: noarch и когда его применять
• Как автоматически формировать BuildRequires
• Как оформить CLI-скрипты в %files
• Куда устанавливаются Python-пакеты и почему
• Как находить и разрешать зависимости Python-пакетов

Немного о Python-упаковке

Прежде чем приступить, давайте разберемся в экосистеме Python-упаковки — она, к сожалению, исторически запутанная.

Форматы и инструменты

• setuptools + setup.py — классический способ. Файл setup.py содержит Python-код, описывающий пакет. Старый подход, но все еще широко используется.
• pyproject.toml — современный стандарт (PEP 517/518). Декларативный формат: вы описываете пакет в TOML-файле, а не пишете Python-код. httpie использует именно его.
• wheel (.whl) — бинарный формат дистрибуции Python-пакетов. Это ZIP-архив с уже собранным пакетом. RPM-макросы сначала создают wheel, потом устанавливают из него.
• egg — устаревший формат (предшественник wheel). Не используйте для новых пакетов.

Как это работает в RPM

В ROSA (и Fedora) для Python-пакетов есть набор макросов %pyproject_*:

%pyproject_buildrequires   →  автоматически определяет зависимости для сборки
%pyproject_wheel           →  собирает wheel из исходников
%pyproject_install         →  устанавливает wheel в %{buildroot}
%pyproject_save_files      →  создает список файлов для секции %files

Эти макросы избавляют вас от ручной работы: не нужно вызывать pip, python setup.py или разбираться в деталях установки — макросы делают все правильно.

Что такое BuildArch: noarch

Это важный концепт, и новички часто путаются.

BuildArch: noarch означает, что пакет не зависит от архитектуры процессора. Он одинаково работает на x86_64, aarch64, любой другой архитектуре.

Когда использовать noarch:

• Чистый Python-код (без C-расширений)
• Скрипты (bash, Perl, Ruby)
• Документация, конфигурации, данные

Когда НЕ использовать noarch:

• Python-пакет содержит C-расширения (.so файлы) — например, numpy, lxml
• Пакет компилируется под конкретную архитектуру

httpie — это чистый Python, поэтому BuildArch: noarch. Готовый RPM попадет в ~/rpmbuild/RPMS/noarch/ (а не x86_64).

Куда устанавливаются Python-пакеты

В RPM-мире есть два макроса для путей Python-пакетов:

Разница в /usr/lib vs /usr/lib64:

• sitelib — для платформонезависимого кода (.py файлы)
• sitearch — для платформозависимого кода (скомпилированные .so модули)

Для httpie используется %{python3_sitelib}, потому что это чистый Python.

Чтобы узнать точные пути на вашей системе:

rpm --eval '%{python3_sitelib}'
# /usr/lib/python3.12/site-packages

rpm --eval '%{python3_sitearch}'
# /usr/lib64/python3.12/site-packages

Содержание практикума

• Подготовка окружения и скачивание исходников
• Создание SPEC-файла
• Сборка, проверка и установка пакета
• Что делают %pyproject_* макросы за кулисами
• Ошибки новичков и советы по отладке