[Moscow.pm] Установка модуля.

Orlovsky Alexander nordicdyno на yandex.ru
Ср Авг 27 00:56:04 PDT 2008


> > А как, кстати, это делается?
> > Я пока вижу только такой путь:
> > 1) собираем локально Bundle-модуль с помощью Module::AutoInstall (Module::Install) в котором перечисим CPAN-зависимости для нашего не-CPAN модуля.
> > 2) Затем:
> >  % make checkdeps
> >  % make installdeps
> >
> > А как еще можно?
> В M::I есть AutoInstall, который добавляет функцию auto_install().
> Дергаем ее и в время make будут поставлены зависимости, которых нет в
> системе. На сколько я знаю, у этого метода есть недостатки, что его
> даже хотели исключить из M::I, но по прозьбе трудящихся вернули на
> место.

Да, это в принципе тот же Module::AutoInstall завернутый в функцию. И про глючность я уже на nntp.perl.org успел прочитать. M::I там величают evil-ом именно из-за того, что тянет с собой Module::AutoInstall :) 

> Вот так мы делаем в РТ:
> http://svn.bestpractical.com/cgi-bin/index.cgi/bps/view/rt/3.8/trunk/sbin/rt-test-dependencies.in
> Там есть функция resolve_deps, но практика показывает, что люди не
> хотят этим пользоваться, а хотят все ставить из пакетов системы или
> возникают трудности. Трудности различного характера. Например какой-то
> автор забыл поднять/установить зависимости и тесты разваливаютсю. С
> системными пакетами тоже фигня. По неизвестным причинам в некторых
> дистрибутивах Scalar::Util собран без weaken.

Посмотрел. Т.е. используется свой велосипед. (в смысле не "стандартный" модуль установки).

А вообще у меня задача проще, мне не нужно сверх-портабельный инсталятор, достаточно того чтобы он работал на относительно "стандартной" конфигурации. Т.е. вариант когда Scalar::Util собран без weaken -- исключительный и не должен обрабатываться.

> Мы написали M::I::RTx для распихивания по своим директориям файлы
> расширений RT. Грязно, но работает как нам надо :)

О, это ("распихивания по своим директориям ") то чего и мне не хватает в "стандартных модулях" (насколько я их успел посмотреть). 

> >> > наверное лучше всего написать свое правило.. подскажите как? :)
> >> Оно вам надо?

Вопрос хороший. Возможно... в смысле повышения "образованности". А так, конечно, могу и обойтись :)

> У нас есть не веб приложение svk, которое ставится как модули + скрипт
> в стандартный bin/. Вполне себе работает.
> Мечтаю о Module::Install::Application, который сможет поставить
> файлики используя install, пофиксить права и прочее, но не в
> директории перла.

И почему он до сих пор не написан? :)

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

> >
> > Понятно, что можно написать свой набор скриптов, с помощью которых собирать/разворачивать свой perl-soft, но не хочется изобретать свой велосипед с квадратными колесами :)
> drupal разворачивается красиво - распаковал, apache направил,
> небольшой визард и все.

Да, есть такое. Ставил когда-то. Там инсталятор заточен на "конечного юзера" по понятным причинам.

> > Нашел совсем недавно в CPAN-е Shipwright. Вроде что-то похожее на то что я хочу. Интересная "штука". Смущает только review на http://cpanratings.perl.org/dist/Shipwright, где сетуют на недостаточность документации. Насколько это правда? (Уже не успеваю сегодня посмотреть) Кто-нибудь использует Shipwright или что нибудь подобное?
> Мы его пишем и используем. Пока нам не хватает некоторого функционала
> для полноценного использования и наш коллега активно работает над
> второй версией.

Тем кто пишет, использовать проще -- документация то особо не нужна. Понятно, если что, то всегда можно заглянуть в код, но это занимает время и "анноит ". :)

> > P.S.
> > Вот думаю, что возмжно не стоит заморачиваться и пойти по пути наименьшего сопротивления, взяв тот же ant + набор скриптов/конфигов и собиратьcя так? Зачем вообще нужен Shipwright? :)
> Чтобы запаковать все в один дистрибутив. И одной командой развернуть
> RT со всеми зависимостями и при необходимости с apache, mysql, gd и
> прочими бинарными библиотеками и программами. Это одно из назначений.
> Еще для ведения репозитория зависимостей. Еще для тестирования RT с БД
> mysql, Pg или SQLite. С серверами apache+fcgi, apache+mod_perl, nginx
> и lighttpd.

Функционал похоже богатый. Возможно для моих задач и ant-а хватит, но Shipwright посмотрю.

Спасибо за развернутый ответ!  
*ушел ставить Shipwright*


Подробная информация о списке рассылки Moscow-pm