Re: [devel] pythonegg requires; was: Re: Вопросы по развитию python.

[Alexey Tourbin <alexey.tourbin@gmail.com>]

2016-05-29 20:41 GMT+03:00 Ivan Zakharyaschev <imz@altlinux.org>:
>>>> А для чего требуются зависимости .egg-info? Влияет ли их формальное
>>>> нарушение на работоспособность кода, как в случае pkg-config?
>
>> Я сначала вас не понял. Вы пишете слишком специфически и по делу. Как
>
> Тогда я написал не по делу, хотя на похожие темы, и то, что я собирался
> отметить в какой-то записке.
>
> Ведь речь-то шла про работоспособность и egg-info, и стоит ли её отражать в
> Requires. А то, про что я стал рассказывать, было про отказ работать во
> время сборки из-за несоответствия формально записанного в setup.py и
> фактически установленного в сборочной среде. (Т.е. и не про egg-info
> непосредственно. Про поведение setuptools.)

Здравствуйте. Хорошо, что продолжили эту тему. А чем отличаются
setup-tools и egg-info? Это какие-то совсем разные вещи из разных
опер? (Я не специалист по питону, правда-правда! Хотя может и смогу
написать несложный list comprehension в квадратных скобках.) Мне не
понятно, какие вещи там с какой горы берутся. Поэтому я и написал, что
у вас всё слишком специфически и по делу; а я, к сожалению, плохо
понимаю в более общем плане, как эта экосистема устроена.

В общем, если можете, и если это займет у вас не очень много рабочего
времени (допустим, не больше двух часов), то напишите, пожалуйста,
короткий обзор, как собираются питоновские модули, с учетом всяких
сторонних прибамбасов. Думаю, это будет интересно не только мне.

> Из области поведения setuptools была, кстати, и проблема run-time (когда
> сообщили и bugzilla, что gnome-music не запускался). Там в пакетах прописана
> информация о зависимостях, которую воспринимают setuptools (в setup.py). И,
> совершая установку пакета, setuptools создают "точки входа" в виде
> исполняемых файлов, в которых питоновский код использует pkg_resources, а
> там происходит проверка того, что все зависимости из информации о пакете
> установлены. Эта проверка работает в runtime. Информация о зависимостях
> читается, записанная в каких-то pkginfo или egg-info.

Вы тут пишете, что gnome-music мог бы запуститься, но не запускается
из-за формальных требований. То есть формальные требования из setup.py
(грубо говоря, со стадии configure) каким-то образом переносятся на
стадию запуска. Я не совсем понимаю, как это делается, а главное,
зачем это делается?

Идеология традиционной сборки rpm-пакетов состоит в том, что: 1)
стадия configure определяет, можно собрать или нельзя; если собрать
нельзя, то rpm бессилен; 2) если собрать удалось, то в конце rpm
определяет зависимости и другие существенные особенности среды сборки,
так чтобы запуск был вполне возможен и после "переноса"; 3)
соответственно, после "переноса" в рантайме никаких проверок не
происходит; запуск более-менее гарантирован статическими
rpm-зависимостями.

Эта fine model рушится, если любой дурак будет проверять при запуске,
хочет он запускаться или не хочет. Например, перловый модуль DB_File
(Berkeley DB) может встать в позу и поверять при запуске, слинкован ли
он с той же самой версией Berkeley DB, которую видел при компиляции.
Это реальный случай.

--- a/ext/DB_File/version.c
+++ b/ext/DB_File/version.c
...
-    if (Major != DB_VERSION_MAJOR || Minor != DB_VERSION_MINOR
-               || Patch != DB_VERSION_PATCH)
+    if (Major != DB_VERSION_MAJOR || Minor != DB_VERSION_MINOR )
+               /* || Patch != DB_VERSION_PATCH) */
                       croak("\nDB_File needs compatible versions of libdb...");

http://search.cpan.org/diff/DB_File-1.815-DB_File-1.816.diff

Мне кажется, что все эти доморощенные подзаборные варианты domestic
package management нужно бить по носу.

Здесь есть еще одно соображение: если код не сможет нормально
отработать, то он не отработает нормально в любом случае, так или
иначе, рано или поздно. Поэтому в рантайме нам не нужен циничный
прорицатель. Если балерина выбежала на сцену, то уже нет смысла
проверять, в форме она или нет. Пусть уж спляшет хоть как нибудь.

Есть еще соображения насчет доказуемых и недоказуемых зависимостей. Я
писал об этом подробнее где-то рядом. Я всегда занимался только
доказуемыми зависимостями. Доказуемые зависимости довольно
реалистичны. Например, set-версии реалистичны: не нужно запускать
программу, если ей не хватает функций в библиотеках. Такая программа
упадет во время вызова недостающей функции, к бабке не ходи. И есть
еще авторитетные зависимости, например, требуется версия foo >= 666.
Это, по-моему, вообще не зависимости в понятном мне смысле, а какие-то
чревовещания.

Вы еще интересно упомянули про buildreq. Наверное подумаю и еще
отвечу. Хотя кому сейчас нужен buildreq.