Проблема python3-зависимостей в пакетах в Sisyphus (Данила Загайнов, OSSDEVCONF-2022)
Материал из 0x1.tv
- Докладчик
- Данила Загайнов
В Sisyphus для работы с пакетами, имеющими python3 зависимости, а также предоставляющими python3 provides, используется rpm-build-python3.
Содержание
Видео
Thesis
http://git.altlinux.org/gears/r/rpm-build-python3.git — Этот пакет потребовал серьёзной доработки и вот что уже было сделано:
- После выхода python 3.10 rpm-build-python3 стал непригоден, так как python3.req.py, его компонент для определения зависимостей, использовал модули parser и symbol, более не поддерживаемые в свежих релизах python3.
Поэтому python3.req.py был переписан, используя модуль ast.
Вот что уже готово к внедрению:
- определение зависимостей при использовании importlib
- отключение поиска зависимостей для кодировок
Вот что планируется к внедрению:
- более грамотное определение provides, предоставляемых пакетом
- предоставление возможности использования python3.req.py не только лишь при сборке
- вынесение python3.req.py в отдельный модуль
Определение python 3 зависимостей
Для определения python3 зависимостей в Sisyphus используется python3.req.py, компонент пакета rpm-build-python3. Первоначально для этой процедуры были задействованы модули parser и вспомогательно symbol. В конечном итоге этот процесс сводился к рекурсивному распарсиванию кода по частям вплоть до нахождения искомого символа или до упора.
Однако при разработке rpm-build-python3 0.1.18 и переписывании кода python3.req.py был применён модуль ast, а модули parser и symbol были отброшены. Как следствие, алгоритм обработки кода целевого файла свёлся к прохождению по дереву AST и поиску объектов типа ast.Import, ast.ImportFrom и т.д.. В качестве бонуса python3.req.py стал работать быстрее и пропало порождение одинаковых зависимостей при обработке конструкций __import__(smth).
Приятным последствием переписывания python3.req.py стала возможность включить определения зависимостей при использовании конструкций importlib, а также отключение поиска зависимостей для кодировок. Однако обе опции пока не были внедрены. Внедрение importlib допускает возникновение проблемы при определении зависимостей, создаваемых конструкциями вида:
smth = 'os'
importlib.import_module('%s' % smth)
Определение self-provides
Однако после определения зависимостей остаётся вопрос, а все ли зависимости могут быть удовлетворены дополнением к подмножеству, называемым в рамках задачи исследуемым пакетом, множества всех пакетов Sisyphus? Сам пакет может предоставлять свои собственные сабмодули и даже целый модуль, то есть его self-provides должны быть исключены из списка его зависимостей. Для этого получившиеся зависимости проходят постобработку путём фильтрации через список provides, предоставляемых данным пакетом.
Сами же provides формируются из тех файлов, которые попали к python3.req.py.
В случае если пришедший путь к файлу содержит суффикс из sys.path, тогда можно предположить, что это какой-то модуль, который может содержать self-provides и тогда запускается рекурсивный проход по всему модулю. Однако существуют случаи, когда пакет ничего явно не провайдит, а содержит лишь какие-то свои «плагины». Вероятно, что компоненты пакета могут пытаться импортировать такие плагины, однако провайдить их он не собирается. На этот случай в python3.req.py была реализована переменная окружения RPM_PYTHON3_IMPORT_PATH, в которую раскрывается макрос %_python3_import_path.
Через этот макрос добавляются дополнительные пути, по котором python3.req.py должен определить provides. Также этот макрос весьма удобен в случаях, когда сборка пакета разбивается на 2 разных подпакета, но при этом компоненты одного импортируют компоненты другого.
!.jpg)