From: Daniel <kotopesutility@yandex.ru> To: devel@lists.altlinux.org Subject: [devel] rpm-build-python3 0.1.20-alt1 Date: Mon, 14 Nov 2022 01:44:39 +0300 Message-ID: <Y3FywAH3BlRYgzXN@bouledoguefrancais> (raw) [-- Attachment #1: Type: text/plain, Size: 6225 bytes --] Добрый вечер! Как я уже говорил на своем докладе в Переславле этой весной, появилась необходимость в механизме, позволяющем добавлять дополнительные пути для 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 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --]
next reply other threads:[~2022-11-13 22:44 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-13 22:44 Daniel [this message] 2023-02-11 9:47 ` Vitaly Lipatov 2023-02-11 11:30 ` Grigory Ustinov 2023-02-12 21:37 ` Daniel
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Y3FywAH3BlRYgzXN@bouledoguefrancais \ --to=kotopesutility@yandex.ru \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git