[sisyphus] Re: [sisyphus] Давайте спорить. О Perl?
Alexey Morozov
=?iso-8859-1?q?morozov_=CE=C1_novosoft=2Eru?=
Ср Май 23 15:02:33 MSD 2001
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.
>Оставьте кучу там, где ей лежать хорошо.
>
Хех, "а рыбки-то хочется".
Подробная информация о списке рассылки Sisyphus