Добрый вечер!

    Как я уже говорил на своем докладе в Переславле этой весной,
    появилась необходимость в механизме, позволяющем добавлять
    дополнительные пути для 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