[devel] rpm-build-python3 0.1.20-alt1
Daniel
kotopesutility на yandex.ru
Пн Ноя 14 01:44:39 MSK 2022
Добрый вечер!
Как я уже говорил на своем докладе в Переславле этой весной,
появилась необходимость в механизме, позволяющем добавлять
дополнительные пути для python3.req.py (компонента
rpm-build-python3) для поиска self-provides. Для этого мы
реализовали макрос %_python3_self_prov_path и макрос
%%add_python3_self_prov_path, дополняющий значение
первого. Пример использования можно найти здесь:
https://git.altlinux.org/tasks/309954/gears/200/git?p=git;a=commitdiff;h=f3b5290fa3381556d2f3d85e7c65d05db89828c4
>%add_python3_self_prov_path %buildroot%llvm_prefix/lib/libscanbuild
После подобного использования python3.req.py поищет
дополнительные provides внутри %buildroot%llvm_prefix/lib/libscanbuild,
что помогает в случае определения зависимостей для файла
/usr/lib/llvm-15.0/bin/scan-build-py. Данный файл
импортирует libscanbuild, переопределяя свой sys.path,
благодаря чему данный import сработает. Так как
python3-req-py не знает об этой темной магии, то ему нужно
помочь, явно указав, путь к libscanbuild.
По ходу дела также было обнаружено, что некоторые upstream-ы
не только злостно извращаются с путями, но и порой тащат с
собой спрятанные модули, которые совпадают по именам с
реально существующими модулями. Например, пакет
python3-module-hypothesis в своем файле
/usr/lib/python3/site-packages/hypothesis/extra/dpcontracts.py
импортирует dpcontracts (данный пример особенно странный,
посколько совпали не только имена self-provide и стороннего
модуля, но и вызывающей программы). Ранее python3-req-py
пропускал эту зависимость, якобы удовлетворяемую
self-provides-ами. Конкретно здесь это как будто бы не очень
критично, раз за все это время никто не столкнулся с
проблемой отсутствия данной зависимости в Sisyphus, однако,
так могут пропасть зависимости куда более существенные
(например, приносит upstream с собой requests).
Поэтому нам пришлось несколько изменить логику определения
зависимостей, в соответствии с местоположением файлов. Если
путь к файлу содержит суффикс из sys.path, тогда это, скорее
всего, модуль, предназначенный строго для import-а. Тогда
внутри него будут работать только лишь относительные (from .
import smth) и абсолютные (это топовый модуль и его
сабмодули, например, ansible) импорты, но локальные импорты
работать не смогут (модуль /usr/lib/python3/site-packages/m
содержит a.py и b.py, внутри a.py import b). То есть,
используя относительный import, импортируется что-то явно с
собой принесенное. В случае же абсолютного import-а, явно
импортируется что-то общедоступное (пусть также принесенное с
собой, но видное всем). Все остальное это уже хуки с
sys.path. Тогда мы в свою очередь через self-provides
фильтруем лишь относительные и абсолютные импорты, локальные
не трогаем.
Если пути к файлам не содержат в себе суффикса из sys.path,
тогда это что-то, что явно не сможет проимпортироваться,
тогда это какие-то скрипты, которые кто-то будет как-то
запускать, тогда мы уже проверяем через провайдсы все.
Из-за появления отдельной логики для случая с суффиксом из
sys.path среди зависимостей могут начать всплывать
self-provides. Таких случаев не очень много, все я готов
исправить, но не везде хватает прав (см. задания 309935 и
309952). В обоих случаях пути к self-provides обмазывается
%add_python3_self_prov_path, описанным выше. Тогда
получаемые зависимости фильтруются через новые
self-provides, независимо от того, как они были получены
(относительным, абсолютным или локальным импортом).
Возвращаясь к приятным аспектам обновления, теперь можно не
отфильтровывать __main__ руками + теперь зависимости,
получаемые importlib-ом, определяется по дефолту.
--
kotopesutility
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : signature.asc
Тип : application/pgp-signature
Размер : 833 байтов
Описание: отсутствует
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20221114/a8c3e398/attachment-0001.bin>
Подробная информация о списке рассылки Devel