ALT Linux Team development discussions
 help / color / mirror / Atom feed
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 --]

             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