Re: [sisyphus] Re: [sisyphus] Давайте спорить. О Perl?

[Alexey Morozov <morozov@novosoft.ru>]

Mikhail Zabaluev wrote:

>>>А что, и расскажу. Когда мы с Дмитрием обсуждали авто-зависимости для
>>>Perl, никаких общепринятых схем, кроме perl-Some-Module в имени
>>>пакета, на горизонте не было. Выбранная схема позволяет включать в
>>>
>>Гхм. Насколько я понимаю ситуацию, уже в 98 году у меня были модули, 
>>собранные именно через perl(Test::Module) :-)
>>
>Дистрибутив, plz. Это вряд ли был RH или Mandrake, с которыми имеет
>смысл хотя бы декларировать совместимость.
>
Ну, насколько я понимаю, одним из первых начал повсеместно использовать 
эту схему Кубушин. Но, насколько я понимаю, код был написан не в рамках KSI.

>>Я это все знаю. Более того, пользуюсь. И поэтому не могу сказать: "а, вы 
>>все дураки, один я Д'Артаньян". Но думать надо. Вы не задумывались над 
>>тем, что бы пытаться грузить модуль, а потом анализировать изменения в 
>>%INC? По-видимому, это даст нам _минимальный_ набор требуемых модулей, 
>>хотя, конечно, если модули цепляются через require, там придется еще 
>>подумать, а удается ли их зацепить таким вот образом. Короче, надо
>>
>Загрузка модуля через use чревата побочными эффектами, а в некоторых
>файлах есть злостные блоки, которые выполняются при компиляции. Можно,
>конечно, грузить их в сейфе с запретом на опасные операции, но все же
>надежность и здравость такого решения в плане влияния на процесс
>сборки сомнительна. Тормозить все это будет точно.
>
Гхм... _Тормозить_ (с большой буквы T) - "эт-вряд ли". Работать 
медленнее - да, наверняка.
Есть, конечно, опасность, что соответствующие модули будут гадить в 
"host-process" namespace и прочее, но это надо быть совсем зловредным и 
невоспитанным, насколько я понимаю, в рамках CPAN таковых модулей не 
должно быть много (то есть, _очень немного_). Для особых параноиков 
можно fork'аться и всю грязную работу проводить в отдельном процессе с 
контролем по времени исполения etc etc. Но факт, что руками пытаться 
вылавливать все use/require/do/eval - более чревато, и сильно менее 
прозрачно.

>>>ненавидите Perl так, как ненавижу его я? :)
>>>
>>Это наша родина, сынок" :-)
>>
>Ну нееет. Я уже собрал свой чемодан для переезда в Python.
>
А что, есть коммерческий спрос на программистов на python? Где 
записываться? :-)

>>Собственно, большой разницы, что цеплять perl(Test/Module.pm) или 
>>perl(Test::Module) я не вижу (разве что, второе более наглядно и, 
>>наверное, более портабельно между системами :-)).
>>
>Вы видели где-нибудь эти зависимости perl(Test::Module)? Я,
>признаться, долго не подымал головы, чтобы поглядеть через забор...
>
У KSI. У себя. Где-то еще, где пытаются автоматизировать процесс сборки 
и думают о последствиях (дебиан?). Но на самом деле, эта часть (включая 
зависимости по другим языкам/типам) - похоже, стала или становится 
стандартом в rpm-based distros. По крайней мере, в стоящем у меня RPM4 
имени Mdk8 вполне присутствует файл /usr/lib/rpm/find-req.pl (хотя это 
shell-скрипт и им, похоже, никто не пользуется :-)), аналогичный тому, 
что я подсмотрел в AltLinux'овом rpm-build. Тоже пытается догадаться, 
кто такой, и натравить соответствующую программу поиска зависимостей.

>Повторюсь, этот вопрос мы однажды обдумали и решили так, как
>решили. Какой-нибудь foo/bar.ph ведь не запишешь через
>двоеточия. Кстати, почему я не слышу ругательств насчет версий с
>эпохами? :)
>
:-). Рука бойцов колоть устала. :-)

>>Глядя на размер CPAN начинаешь тосковать по более полезному применению 
>>"высшей нервной" :-)
>>
>На самом деле, плохого для наших скриптов кода в популярных модулях
>не так уж и много. Авторы правильного Perl не такие уж и грязные
>недисциплинированные хакеры, как можно себе представить :)
>
:-) О чем и речь. Но все же, недостаточно дисциплинированные, чтобы 
говорить use Bla::Bla; в начале и успокаиваться :-)

>И потом, никто не собирается паковать в дистрибутив весь CPAN.
>Оставьте кучу там, где ей лежать хорошо.
>
Хех, "а рыбки-то хочется".