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

[Ivan Zakharyaschev]

On Thu, 19 May 2016, Alexey Tourbin wrote:

> 2016-05-18 20:32 GMT+03:00 Ivan Zakharyaschev <imz на altlinux.org>:
>>> А для чего требуются зависимости .egg-info? Влияет ли их формальное
>>> нарушение на работоспособность кода, как в случае pkg-config?

> Я сначала вас не понял. Вы пишете слишком специфически и по делу. Как

Тогда я написал не по делу, хотя на похожие темы, и то, что я собирался 
отметить в какой-то записке.

Ведь речь-то шла про работоспособность и egg-info, и стоит ли её отражать 
в Requires. А то, про что я стал рассказывать, было про отказ работать во 
время сборки из-за несоответствия формально записанного в setup.py и 
фактически установленного в сборочной среде. (Т.е. и не про egg-info 
непосредственно. Про поведение setuptools.)

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

Этот случай показал, что автопоиск зависимостей можно было бы улучшить, 
чтобы он и эту зависимость автоматически из кода вывел, потому что она 
реально есть. (Но crash был ещё не при попытке это использовать, а при 
специальной проверке.)

Т.е. такая мысль возникает: можно воспринимать несоответствие работы 
поиска автозависимостей и прописанных (кем-то внешним) в метаинформации о 
пакете зависимостей как возможную недоработку поиска автозавимостей 
(feature request на python{,3}.req.py); конечно, если только это не ошибка 
того кого-то внешнего, кто их написал и написал не то по ошибке.

Но если просто исходить из желания, чтоб всё работало, то зависимости из 
метаинформации о пакете надо отражать в requires. Тогда такой случай не 
произошёл бы. Да и теоретически поиск автозависимостей не может дать 
полный результат, поэтому разумно пользоваться другой дополнительной, 
написанной людьми информацией.

Дальше -- про отказы работать во время сборки:

>> Насколько я понимаю, ситация очень похожа. Кое-что может отказаться
>> работать, если эти формальные зависимости не удовлетворены в сборочной
>> среде, хотя фактически они не используются.
>>
>> Это пришлось учесть в
>> http://git.altlinux.org/gears/p/python-module-setuptools.git?p=python-module-setuptools.git;a=commitdiff;h=362ea68c65bba0dad283fdd0b1681fbc3181f1d4
>> и
>> http://git.altlinux.org/gears/p/python-module-setuptools.git?p=python-module-setuptools.git;a=commitdiff;h=486acaedf91610ac254184ed7cc0f9d7e0bdbe2b
>> , т.е. формальные записи не учитывать или не проверять наличие системных
>> пакетов.
>
> То есть вы хотели сказать, что вы фактически отключили проверку
> формальных зависимостей при сборке всех питоновских модулей? А какой
> системы зависимостей это касается, .egg-info или еще какой-то? И
> почему вы думаете, что это хорошо? В конце концов, зачем вы это
> сделали?
>
> Если немного обобщать, то имеется проблема "параллельной системы
> зависимостей". Есть нативная система зависимостей, и есть rpm, который
> strives to catch up. Потуги rpm, кажется, никому не нужны, это
> nuisance for everybody.
>
>> Хочется обратить внимание на это и попросить тех, кто будет в будущем
>> заниматься питоном и обновлять setuptools или аналогичные по функциями
>> пакеты, учесть эти полезные для сборки в ALT "хаки".
>
> А что этим вы хотели сказать? Вы даете ценные указания потомкам на
> случай вашего весьма вероятного отхода от дел? Да никто больше не
> будет собирать питон скрупулезно. Все это никому не надо, к сожалению.

Да. Я уже знаю о планах viy@ (и надеюсь на них) по массовому 
автоматизированному обновлению питоновских пакетов. Конечно, setuptools по 
сути не из этой общей массы, а занимает особое положение.

И хотелось где-то записать, какие изменения в нём оказались полезны на 
пути к избавлению от излишних сборочных зависимостей и циклов среди 
питоновых пакетов. Это небольшие улучшения, которые удаются использованием 
дистрибутивных средств, без вникания в отдельные пакеты.

Лишние сборочные зависимости и циклы в любом случае и в будущем будут 
проблемой для набора питоновых пакетов в Sisyphus, которую надо будет 
стараться обходить и всегда уметь обходить.

Точнее подробности такие:

Первая проблема была такая: sem@ ставил сборочные зависимости по данным 
buildreq (в надежде где-то их сократить), в результате, некоторые пакеты 
перестали собираться из-за искусственных проверок зависимостей, указанных 
в их steup.py, но фактически не использованных (по данным buildreq). 
glebfm@ внёс первое изменение в setuptools, чтобы при сборке rpm этой 
проверки не делалось, а мы полагались бы на RPM-сборочные-зависимости 
(записанные в spec).

Вторая проблема была такая (могла появиться как результат применения 
buildreq): setuptools заглядывали в некоторые места при сборке, которые с 
точки зрения buildreq создавали зависимости, а фактически оно было 
необзятельным. Примеры, которые заставили на это обратить, были очень 
короткими сборочными циклами, например, пакет сам себя требовал только 
потому, что setuptools выясняло версию установленного пакета такого 
названия для создания своего какого-то внутреннего объекта -- по смыслу 
"пакет". И я просто изменил это поведение (чтобы можно было более 
осмысленно пользоваться buildreq): при сборке RPM не выяснять версии, а 
использовать какое-то значение по умолчанию (которое в коде уже было 
предусмотрено).

Кажется, иногда похожей на вторую проблему страдает sphinx: начинает для 
генерации документации читать не только что собранный код, а код из 
установленных в сборочной среде пакетов. (Записал это в bug-report-е 
тогда, когда заметил.)

-- 
Best regards,
Ivan