* [devel] Вопросы по развитию python. @ 2016-05-17 18:44 Igor Vlasenko 2016-05-18 16:07 ` Alexey Tourbin 0 siblings, 1 reply; 14+ messages in thread From: Igor Vlasenko @ 2016-05-17 18:44 UTC (permalink / raw) To: devel Господа, Пока сборочница не работает, можно обсудить накопившиеся вопросы по питону. 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] Вопросы по развитию python. 2016-05-17 18:44 [devel] Вопросы по развитию python Igor Vlasenko @ 2016-05-18 16:07 ` Alexey Tourbin 2016-05-18 16:40 ` Igor Vlasenko 2016-05-18 17:32 ` [devel] pythonegg requires; was: " Ivan Zakharyaschev 0 siblings, 2 replies; 14+ messages in thread From: Alexey Tourbin @ 2016-05-18 16:07 UTC (permalink / raw) To: ALT Linux Team development discussions 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? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] Вопросы по развитию python. 2016-05-18 16:07 ` Alexey Tourbin @ 2016-05-18 16:40 ` Igor Vlasenko 2016-05-18 17:25 ` Alexey Tourbin 2016-05-18 17:32 ` [devel] pythonegg requires; was: " Ivan Zakharyaschev 1 sibling, 1 reply; 14+ messages in thread From: Igor Vlasenko @ 2016-05-18 16:40 UTC (permalink / raw) To: ALT Linux Team development discussions 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] Вопросы по развитию python. 2016-05-18 16:40 ` Igor Vlasenko @ 2016-05-18 17:25 ` Alexey Tourbin 2016-05-18 18:02 ` Igor Vlasenko 0 siblings, 1 reply; 14+ messages in thread From: Alexey Tourbin @ 2016-05-18 17:25 UTC (permalink / raw) To: ALT Linux Team development discussions 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 у них разный. Интересно, что вы думаете в терминах изоморфизма дистрибутивов, а не в терминах конвергенции. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] Вопросы по развитию python. 2016-05-18 17:25 ` Alexey Tourbin @ 2016-05-18 18:02 ` Igor Vlasenko 2016-05-18 20:31 ` Alexey Tourbin 0 siblings, 1 reply; 14+ messages in thread From: Igor Vlasenko @ 2016-05-18 18:02 UTC (permalink / raw) To: ALT Linux Team development discussions 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] Вопросы по развитию python. 2016-05-18 18:02 ` Igor Vlasenko @ 2016-05-18 20:31 ` Alexey Tourbin 2016-05-19 19:32 ` Igor Vlasenko 0 siblings, 1 reply; 14+ messages in thread From: Alexey Tourbin @ 2016-05-18 20:31 UTC (permalink / raw) To: ALT Linux Team development discussions 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", и вообще призываю вас думать головой менее оппортунистически. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] Вопросы по развитию python. 2016-05-18 20:31 ` Alexey Tourbin @ 2016-05-19 19:32 ` Igor Vlasenko 0 siblings, 0 replies; 14+ messages in thread From: Igor Vlasenko @ 2016-05-19 19:32 UTC (permalink / raw) To: ALT Linux Team development discussions On Wed, May 18, 2016 at 11:31:46PM +0300, Alexey Tourbin wrote: > Я не согласен с терминами поставленной задачи "спереть пакет А из > дистрибутива B", и вообще призываю вас думать головой менее > оппортунистически. Можно сказать по другому. Есть питон, надо его сопровождать. Иван проделал большую работу по обновлению 3-го питона до 3.5, но ему тяжело. Мне тоже страшно браться, но руку помощи хочу протянуть. у меня есть опыт по работе с perl, поэтому хотя сейчас за пакеты питона не берусь, готовлю всех своих роботов к тому, чтобы иметь возможность при необходимости подключить их и к питону. Сейчас как раз занимаюсь сервисом watch - строю изоморфизмы пакетной базы, чтобы сравнивать версии и предупреждать об обновлениях. -- I V ^ permalink raw reply [flat|nested] 14+ messages in thread
* [devel] pythonegg requires; was: Re: Вопросы по развитию python. 2016-05-18 16:07 ` Alexey Tourbin 2016-05-18 16:40 ` Igor Vlasenko @ 2016-05-18 17:32 ` Ivan Zakharyaschev 2016-05-19 17:19 ` Alexey Tourbin 1 sibling, 1 reply; 14+ messages in thread From: Ivan Zakharyaschev @ 2016-05-18 17:32 UTC (permalink / raw) To: ALT Linux Team development discussions [-- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] pythonegg requires; was: Re: Вопросы по развитию python. 2016-05-18 17:32 ` [devel] pythonegg requires; was: " Ivan Zakharyaschev @ 2016-05-19 17:19 ` Alexey Tourbin 2016-05-29 17:41 ` Ivan Zakharyaschev 0 siblings, 1 reply; 14+ messages in thread From: Alexey Tourbin @ 2016-05-19 17:19 UTC (permalink / raw) To: ALT Linux Team development discussions 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 "хаки". А что этим вы хотели сказать? Вы даете ценные указания потомкам на случай вашего весьма вероятного отхода от дел? Да никто больше не будет собирать питон скрупулезно. Все это никому не надо, к сожалению. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] pythonegg requires; was: Re: Вопросы по развитию python. 2016-05-19 17:19 ` Alexey Tourbin @ 2016-05-29 17:41 ` Ivan Zakharyaschev 2016-05-29 19:15 ` Alexey Tourbin 0 siblings, 1 reply; 14+ messages in thread From: Ivan Zakharyaschev @ 2016-05-29 17:41 UTC (permalink / raw) To: ALT Linux Team development discussions [-- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] pythonegg requires; was: Re: Вопросы по развитию python. 2016-05-29 17:41 ` Ivan Zakharyaschev @ 2016-05-29 19:15 ` Alexey Tourbin 2016-05-29 19:25 ` Michael Shigorin 2016-05-29 20:59 ` Alexey Tourbin 0 siblings, 2 replies; 14+ messages in thread From: Alexey Tourbin @ 2016-05-29 19:15 UTC (permalink / raw) To: ALT Linux Team development discussions 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] pythonegg requires; was: Re: Вопросы по развитию python. 2016-05-29 19:15 ` Alexey Tourbin @ 2016-05-29 19:25 ` Michael Shigorin 2016-05-29 20:59 ` Alexey Tourbin 1 sibling, 0 replies; 14+ messages in thread From: Michael Shigorin @ 2016-05-29 19:25 UTC (permalink / raw) To: devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] pythonegg requires; was: Re: Вопросы по развитию python. 2016-05-29 19:15 ` Alexey Tourbin 2016-05-29 19:25 ` Michael Shigorin @ 2016-05-29 20:59 ` Alexey Tourbin 2016-05-30 6:11 ` Alexey Tourbin 1 sibling, 1 reply; 14+ messages in thread From: Alexey Tourbin @ 2016-05-29 20:59 UTC (permalink / raw) To: ALT Linux Team development discussions 2016-05-29 22:15 GMT+03:00 Alexey Tourbin <alexey.tourbin@gmail.com>: > Здесь есть еще одно соображение: если код не сможет нормально > отработать, то он не отработает нормально в любом случае, так или > иначе, рано или поздно. Поэтому в рантайме нам не нужен циничный > прорицатель. Если балерина выбежала на сцену, то уже нет смысла > проверять, в форме она или нет. Пусть уж спляшет хоть как нибудь. Другими словами, циничный прорицатель всегда прорицает верхнюю грань, или худший случай. Но реальные code paths могут пройти ниже верхней грани, и тогда код отработает нормально. Если же код упрется в верхнюю грань, то тогда падение вследствие касания грани логически не отличается от запрета через прорицание. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [devel] pythonegg requires; was: Re: Вопросы по развитию python. 2016-05-29 20:59 ` Alexey Tourbin @ 2016-05-30 6:11 ` Alexey Tourbin 0 siblings, 0 replies; 14+ messages in thread From: Alexey Tourbin @ 2016-05-30 6:11 UTC (permalink / raw) To: ALT Linux Team development discussions 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 и т.д. как есть. Пусть балерина танцует, пусть сборка идет своим чередом; если балерина станцует - то хорошо, а если не станцует - то опережающее предсказание здесь всё равно не нужно. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2016-05-30 6:11 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-05-17 18:44 [devel] Вопросы по развитию python Igor Vlasenko 2016-05-18 16:07 ` Alexey Tourbin 2016-05-18 16:40 ` Igor Vlasenko 2016-05-18 17:25 ` Alexey Tourbin 2016-05-18 18:02 ` Igor Vlasenko 2016-05-18 20:31 ` Alexey Tourbin 2016-05-19 19:32 ` Igor Vlasenko 2016-05-18 17:32 ` [devel] pythonegg requires; was: " Ivan Zakharyaschev 2016-05-19 17:19 ` Alexey Tourbin 2016-05-29 17:41 ` Ivan Zakharyaschev 2016-05-29 19:15 ` Alexey Tourbin 2016-05-29 19:25 ` Michael Shigorin 2016-05-29 20:59 ` Alexey Tourbin 2016-05-30 6:11 ` Alexey Tourbin
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