[devel] Вопросы по развитию python.

[devel] Вопросы по развитию python.

[Igor Vlasenko]

Господа,

Пока сборочница не работает, можно обсудить накопившиеся вопросы по питону.

1) python egg Provides/Requires
Подсмотрел в mageia python egg Provides/Requires, которые можно расставлять
автоматически по .egg-info. к примеру, в mageia
в python-fabulous автовыставлено Provides: pythonegg(2)(fabulous)
в python3-pretend автовыставлено Provides: pythonegg(3)(pretend)   

В pythonegg(2)(fabulous) (2) -- это питон2, а (fabulous) это имя egg.

Хотелось бы и нам такое. Можно начать с того, что утащить с mageia
и добавить в rpm-build-python* как python*egg.prov
и потихоньку пересобрать пакеты, чтобы у них появились provides.

2) замеченный мусор (устаревшие ветви и форки)
python-module-pmw можно смело удалить в пользу python-module-pmw2
зависимостей нет.
python-module-python-mpd можно смело удалить в пользу python-module-mpd

python-module-xlwt-future пора бы удалить в пользу python-module-xlwt
но он явно прописан в BuildReq: следующих пакетов
gdal
python-module-db
python-module-kungfu
python-module-json2xls
python-module-matplotlib
python-module-pandas-highcharts
и там надо сначала убрать из зависимостей.

3). Несовместимость с mageia/fedora в python3.

Заметил, что в mageia/fedora в бинарных модулях используется суффикс
 .cpython-35m-x86_64-linux-gnu.so, вместо нашего .cpython-35m.so
С выходом python 3.6, возможно, стоит тоже перейти на такой же суффикс?



-- 

I V

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

[Alexey Tourbin]

2016-05-17 21:44 GMT+03:00 Igor Vlasenko <vlasenko@imath.kiev.ua>:
> Господа,
>
> Пока сборочница не работает, можно обсудить накопившиеся вопросы по питону.
>
> 1) python egg Provides/Requires
> Подсмотрел в mageia python egg Provides/Requires, которые можно расставлять
> автоматически по .egg-info. к примеру, в mageia
> в python-fabulous автовыставлено Provides: pythonegg(2)(fabulous)
> в python3-pretend автовыставлено Provides: pythonegg(3)(pretend)

Мужчина, здравствуйте.
А чем грозит нарушение зависимостей pythonegg? Являются ли они в
какой-то степени производными и выводимыми из кода, или же они пишутся
в файл .egg-info вручную?

Интересно сравнить их с зависимостями pkg-config. Последние тоже
пишутся в .pc-файлы более-менее вручную. Но в случае, когда
зависимостей pkg-config Requires не хватает, pkg-config откажется
работать. В этом смысле зависимости pkg-config действительно требуются
для работоспособности сборки (на стадии configure, даже если в
остальном они произвольны).

А для чего требуются зависимости .egg-info? Влияет ли их формальное
нарушение на работоспособность кода, как в случае pkg-config?

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

[Igor Vlasenko]

On Wed, May 18, 2016 at 07:07:18PM +0300, Alexey Tourbin wrote:
> 2016-05-17 21:44 GMT+03:00 Igor Vlasenko <vlasenko@imath.kiev.ua>:
> > 1) python egg Provides/Requires
> > Подсмотрел в mageia python egg Provides/Requires, которые можно расставлять
> > автоматически по .egg-info. к примеру, в mageia
> > в python-fabulous автовыставлено Provides: pythonegg(2)(fabulous)
> 
> Мужчина, здравствуйте.
> А чем грозит нарушение зависимостей pythonegg? Являются ли они в
> какой-то степени производными и выводимыми из кода, или же они пишутся
> в файл .egg-info вручную?
> Интересно сравнить их с зависимостями pkg-config. Последние тоже
> пишутся в .pc-файлы более-менее вручную. Но в случае, когда
> зависимостей pkg-config Requires не хватает, pkg-config откажется
> работать. В этом смысле зависимости pkg-config действительно требуются
> для работоспособности сборки (на стадии configure, даже если в
> остальном они произвольны).

С этим полностью согласен, Requires выписывать по egg незачем.
 
> А для чего требуются зависимости .egg-info?

Provides: pythonegg(2)(fabulous) -- дает дистрибутивно 
независимое имя. 

Я как раз занимался обучением робота, чтобы он в разных
дистрибутивах соопоставил бы питоньи пакеты,
несмотря на то, что rpm name у них разный.
С egg-info такая задача резко упрощается, 
ибо можно проверить, из одного яйца ли вылуплены.

К сожалению, даже не во всех пакетах python-module*src.rpm
упакован .egg-info. 91 пакет, где его нет :(

-- 

I V

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

[Alexey Tourbin]

2016-05-18 19:40 GMT+03:00 Igor Vlasenko <vlasenko@imath.kiev.ua>:
> On Wed, May 18, 2016 at 07:07:18PM +0300, Alexey Tourbin wrote:
>> 2016-05-17 21:44 GMT+03:00 Igor Vlasenko <vlasenko@imath.kiev.ua>:
>> > 1) python egg Provides/Requires
>> > Подсмотрел в mageia python egg Provides/Requires, которые можно расставлять
>> > автоматически по .egg-info. к примеру, в mageia
>> > в python-fabulous автовыставлено Provides: pythonegg(2)(fabulous)
>>
>> Мужчина, здравствуйте.
>> А чем грозит нарушение зависимостей pythonegg? Являются ли они в
>> какой-то степени производными и выводимыми из кода, или же они пишутся
>> в файл .egg-info вручную?
>> Интересно сравнить их с зависимостями pkg-config. Последние тоже
>> пишутся в .pc-файлы более-менее вручную. Но в случае, когда
>> зависимостей pkg-config Requires не хватает, pkg-config откажется
>> работать. В этом смысле зависимости pkg-config действительно требуются
>> для работоспособности сборки (на стадии configure, даже если в
>> остальном они произвольны).
>
> С этим полностью согласен, Requires выписывать по egg незачем.

Эх, мужчина, вы слишком быстро согласились. А тут есть над чем
подумать. Когда имеется код с хорошей структурой (напр., ELF), то
поиск зависимостей - это вывод (дедукция, если угодно) по структуре
кода. Когда структура кода плохая, как с интерпретаторами, то мы сидим
на двух стульях: с одной стороны, мы пытаемся анализировать код, с
другой стороны, нам иногда сливают метаинформацию. Анализировать код -
это некоторое эмпирическое и доказуемое начало, а метаинформация - это
ссылка на авторитет. Рассмотрим доказуемые высказывания и авторитетные
высказывания. Авторитетные высказывания обычно сильнее доказуемых. В
качестве компромисса можно принимать только те авторитетные
высказывания, которые имеют прообраз в доказуемых высказываниях. Так,
в perl.req метаинформация используется только для "наращивания версий"
(когда в коде требуемая версия не указана, а в Makefile.PL - указана;
тогда версия добавляется из Makefile.PL).

>> А для чего требуются зависимости .egg-info?
>
> Provides: pythonegg(2)(fabulous) -- дает дистрибутивно
> независимое имя.

Если оно дистрибутивно-независимо только между двумя дистрибутивами, в
число которых не входит Prominent North-American vendor...

Если же нужно дать питонистам простой способ установить нужные пакеты,
то здесь слишком много букв и слишком много скобок. Проще будет
"apt-get install egg2:fabulous". Но питонистов ждет разочарование,
поскольку в стабильных бранчах питоновские пакеты не обновляются, да и
в сизифе тоже не обновляются через пень колоду. Короче, питонистам
проще использовать свою дуду, как она там называется, кажется "pip
install fabulous".

> Я как раз занимался обучением робота, чтобы он в разных
> дистрибутивах соопоставил бы питоньи пакеты,
> несмотря на то, что rpm name у них разный.

Интересно, что вы думаете в терминах изоморфизма дистрибутивов, а не в
терминах конвергенции.

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

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 1917 bytes --]

Здравствуйте!

On Wed, 18 May 2016, Alexey Tourbin wrote:

> 2016-05-17 21:44 GMT+03:00 Igor Vlasenko <vlasenko@imath.kiev.ua>:

>> 1) python egg Provides/Requires
>> Подсмотрел в mageia python egg Provides/Requires, которые можно расставлять
>> автоматически по .egg-info. к примеру, в mageia
>> в python-fabulous автовыставлено Provides: pythonegg(2)(fabulous)
>> в python3-pretend автовыставлено Provides: pythonegg(3)(pretend)

> А чем грозит нарушение зависимостей pythonegg? Являются ли они в
> какой-то степени производными и выводимыми из кода, или же они пишутся
> в файл .egg-info вручную?
>
> Интересно сравнить их с зависимостями pkg-config. Последние тоже
> пишутся в .pc-файлы более-менее вручную. Но в случае, когда
> зависимостей pkg-config Requires не хватает, pkg-config откажется
> работать. В этом смысле зависимости pkg-config действительно требуются
> для работоспособности сборки (на стадии configure, даже если в
> остальном они произвольны).
>
> А для чего требуются зависимости .egg-info? Влияет ли их формальное
> нарушение на работоспособность кода, как в случае pkg-config?

Насколько я понимаю, ситация очень похожа. Кое-что может отказаться 
работать, если эти формальные зависимости не удовлетворены в сборочной 
среде, хотя фактически они не используются.

Это пришлось учесть в 
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 
, т.е. формальные записи не учитывать или не проверять наличие системных 
пакетов.

Хочется обратить внимание на это и попросить тех, кто будет в будущем 
заниматься питоном и обновлять setuptools или аналогичные по функциями 
пакеты, учесть эти полезные для сборки в ALT "хаки".

-- 
Best regards,
Ivan

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

[Igor Vlasenko]

On Wed, May 18, 2016 at 08:25:23PM +0300, Alexey Tourbin wrote:
> > С этим полностью согласен, Requires выписывать по egg незачем.
> 
> Эх, мужчина, вы слишком быстро согласились. А тут есть над чем
> подумать. Когда имеется код с хорошей структурой (напр., ELF), то
> поиск зависимостей - это вывод (дедукция, если угодно) по структуре
> кода. Когда структура кода плохая, как с интерпретаторами, то мы сидим
> на двух стульях: с одной стороны, мы пытаемся анализировать код, с
> другой стороны, нам иногда сливают метаинформацию. Анализировать код -
> это некоторое эмпирическое и доказуемое начало, а метаинформация - это
> ссылка на авторитет. Рассмотрим доказуемые высказывания и авторитетные
> высказывания. Авторитетные высказывания обычно сильнее доказуемых. В
> качестве компромисса можно принимать только те авторитетные
> высказывания, которые имеют прообраз в доказуемых высказываниях. Так,
> в perl.req метаинформация используется только для "наращивания версий"
> (когда в коде требуемая версия не указана, а в Makefile.PL - указана;
> тогда версия добавляется из Makefile.PL).

Да, я это понимаю, просто боялся груздем назваться,
чтобы не лезть в кузов (писать реализацию).
 
> >> А для чего требуются зависимости .egg-info?
> >
> > Provides: pythonegg(2)(fabulous) -- дает дистрибутивно
> > независимое имя.
> 
> Если оно дистрибутивно-независимо только между двумя дистрибутивами, в
> число которых не входит Prominent North-American vendor...

Впрочем, можно обойтись и без egg provides.

> Если же нужно дать питонистам простой способ установить нужные пакеты,
> то здесь слишком много букв и слишком много скобок. Проще будет
> "apt-get install egg2:fabulous". Но питонистов ждет разочарование,
> поскольку в стабильных бранчах питоновские пакеты не обновляются, да и
> в сизифе тоже не обновляются через пень колоду. Короче, питонистам
> проще использовать свою дуду, как она там называется, кажется "pip
> install fabulous".

Я последние месяцы перетряхиваю коды роботов, чтобы 
как раз и нагрузить их задачами импортирования / автообновления 
питона и обновляють до самого свежего состояния.

Все-таки инструменты вроде pip хороши, пока летают
в noarch облаках, но плохи в столкновении с грубой arch-реальностью.

> > Я как раз занимался обучением робота, чтобы он в разных
> > дистрибутивах соопоставил бы питоньи пакеты,
> > несмотря на то, что rpm name у них разный.
> 
> Интересно, что вы думаете в терминах изоморфизма дистрибутивов, а не в
> терминах конвергенции.

Грубо говоря, это естественно получается в терминах поставленной
задачи (спереть пакет А из дистрибутива B) где B может быть
как честный дистрибутив (fc,mga,pld,...), так и src-репозиторий
(CPAN, pypy).

изоморфизм нужно иметь под рукой, чтобы не пытаться спереть то, что уже 
есть.

-- 

I V

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

[Alexey Tourbin]

2016-05-18 21:02 GMT+03:00 Igor Vlasenko <vlasenko@imath.kiev.ua>:
>> Если оно дистрибутивно-независимо только между двумя дистрибутивами, в
>> число которых не входит Prominent North-American vendor...
>
> Впрочем, можно обойтись и без egg provides.

То есть в дистрибутиве не нужно ни egg Requires, ни egg Provides.

>> Интересно, что вы думаете в терминах изоморфизма дистрибутивов, а не в
>> терминах конвергенции.
>
> Грубо говоря, это естественно получается в терминах поставленной
> задачи (спереть пакет А из дистрибутива B) где B может быть
> как честный дистрибутив (fc,mga,pld,...), так и src-репозиторий
> (CPAN, pypy).
>
> изоморфизм нужно иметь под рукой, чтобы не пытаться спереть то, что уже
> есть.

Я не согласен с терминами поставленной задачи "спереть пакет А из
дистрибутива B", и вообще призываю вас думать головой менее
оппортунистически.

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

[Alexey Tourbin]

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

Мужчина, и вы здравствуйте.
Я сначала вас не понял. Вы пишете слишком специфически и по делу. Как
будто вы думаете, что ваш собеседник всеведущ и вездесущ (и поэтому
обязан вас понять). Это, к сожалению, не так. Ваши собеседники
выпивают по вечерам (хорошо если не по утрам).

> Насколько я понимаю, ситация очень похожа. Кое-что может отказаться
> работать, если эти формальные зависимости не удовлетворены в сборочной
> среде, хотя фактически они не используются.
>
> Это пришлось учесть в
> 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 "хаки".

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

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

[Igor Vlasenko]

On Wed, May 18, 2016 at 11:31:46PM +0300, Alexey Tourbin wrote:
> Я не согласен с терминами поставленной задачи "спереть пакет А из
> дистрибутива B", и вообще призываю вас думать головой менее
> оппортунистически.

Можно сказать по другому. Есть питон, надо его сопровождать.
Иван проделал большую работу по обновлению 3-го питона до 3.5,
но ему тяжело.

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

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


-- 

I V

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

[Ivan Zakharyaschev]

[-- Attachment #1: Type: text/plain, Size: 5978 bytes --]


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

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

[Alexey Tourbin]

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.

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

[Michael Shigorin]

On Sun, May 29, 2016 at 10:15:48PM +0300, Alexey Tourbin wrote:
> Хотя кому сейчас нужен buildreq.

Ну здрасьте.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

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

[Alexey Tourbin]

2016-05-29 22:15 GMT+03:00 Alexey Tourbin <alexey.tourbin@gmail.com>:
> Здесь есть еще одно соображение: если код не сможет нормально
> отработать, то он не отработает нормально в любом случае, так или
> иначе, рано или поздно. Поэтому в рантайме нам не нужен циничный
> прорицатель. Если балерина выбежала на сцену, то уже нет смысла
> проверять, в форме она или нет. Пусть уж спляшет хоть как нибудь.

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

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

[Alexey Tourbin]

2016-05-29 23:59 GMT+03:00 Alexey Tourbin <alexey.tourbin@gmail.com>:
> 2016-05-29 22:15 GMT+03:00 Alexey Tourbin <alexey.tourbin@gmail.com>:
>> Здесь есть еще одно соображение: если код не сможет нормально
>> отработать, то он не отработает нормально в любом случае, так или
>> иначе, рано или поздно. Поэтому в рантайме нам не нужен циничный
>> прорицатель. Если балерина выбежала на сцену, то уже нет смысла
>> проверять, в форме она или нет. Пусть уж спляшет хоть как нибудь.
>
> Другими словами, циничный прорицатель всегда прорицает верхнюю грань,
> или худший случай. Но реальные code paths могут пройти ниже верхней
> грани, и тогда код отработает нормально. Если же код упрется в верхнюю
> грань, то тогда падение вследствие касания грани логически не
> отличается от запрета через прорицание.

Вот другой похожий пример, который поясняет "принцип балерины".
Кирилл К. как-то писал в G+:

        Did you know if you have a Makefile containing something like this:

        CFLAGS += $(shell pkg-config libxml-2.0 --cflags)
        LIBS += $(shell pkg-config libxml-2.0  --libs)

        then it will silently not work if pkg-config is not installed,
as GNU Make
        silently ignores error code of a command run by $(shell CMD)?

https://plus.google.com/+KirillKolyshkin/posts/2f78ZevaaqC

Потом он написал еще один пост, в котором попытался "решить" эту
проблему за счет переквизита компиляции в Makefile, примерно так:

have.pkgconfig+libxml2:
        pkg-config --exists libxml-2.0 && echo 1 >$@
%.o: have.pkgconfig+libxml2

К сожалению, я не нашел сейчас этого второго поста (возможно, Кирилл
его стер). Я ответил ему примерно так: какая разница, где у тебя
упадет сборка, на стадии pkg-config или на стадии #include
<libxml/...>? В имеющейся модели сборка проходит как бы в жестяной
банке, в которой собирающийся пакет никак не может повлиять на наличие
своих пререквизитов. На пререквизиты можно повлиять только на уровне
сборочных зависимостей. Так что я бы оставил конструкцию с CFLAGS и
т.д. как есть. Пусть балерина танцует, пусть сборка идет своим
чередом; если балерина станцует - то хорошо, а если не станцует - то
опережающее предсказание здесь всё равно не нужно.