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

Ruslan Zakirov ruz на bestpractical.com
Вт Авг 26 13:41:07 PDT 2008


2008/8/26 Orlovsky Alexander <nordicdyno на yandex.ru>:
>
>
> 26.08.08, 19:58, "Ruslan Zakirov" <ruz на bestpractical.com>:
>
>> > Чего мне хочется. Я хочу создать локальный дистрибутив, при сборке и установке которого тянутся и собираются все CPAN-зависимости (и возможно не только cpan, но это уже следующий этап).
>
>> Их можно тянуть и по другому. Можно самому загрузить модуль CPAN и  заставить его поставить нужные модули в систему.
>
> А как, кстати, это делается?
> Я пока вижу только такой путь:
> 1) собираем локально Bundle-модуль с помощью Module::AutoInstall (Module::Install) в котором перечисим CPAN-зависимости для нашего не-CPAN модуля.
> 2) Затем:
>  % make checkdeps
>  % make installdeps
>
> А как еще можно?

В M::I есть AutoInstall, который добавляет функцию auto_install().
Дергаем ее и в время make будут поставлены зависимости, которых нет в
системе. На сколько я знаю, у этого метода есть недостатки, что его
даже хотели исключить из M::I, но по прозьбе трудящихся вернули на
место.


Вот так мы делаем в РТ:

http://svn.bestpractical.com/cgi-bin/index.cgi/bps/view/rt/3.8/trunk/sbin/rt-test-dependencies.in

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

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


>> > наверное лучше всего написать свое правило.. подскажите как? :)
>> Оно вам надо?
>
> На самом деле, uninstall наверное не очень нужен. Просто было любопытно как свои правила писать.

> Вообще хочется некий (стандартный)механизм сборки, при помощи которого можно было бы установить свой (не-CPAN) набор perl lib-ов и программ, в заданное дерево каталогов, запускать тесты и делать всякое в зависимости от заданных параметров.

У нас есть не веб приложение svk, которое ставится как модули + скрипт
в стандартный bin/. Вполне себе работает.

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

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

drupal разворачивается красиво - распаковал, apache направил,
небольшой визард и все.

> По-началу я смотрел в сторону Module::Install и иже с ними (еще на Module::Build надо будет посмотреть), т.к. они уже дают некий "фреймворк" для тестирования и установки perl кода.
> Почерпнул мысль у brian d foy в его книге "Mastering Perl" (глава "Modules As Programs").
> Она мне понравилась. Правда сам brian похоже свернул все свои разработки в данном направлении, а я вот решил изучить вопрос :)
> Сейчас ужк есть подозрение, что модули для создания CPAN-дистрибуций -- это не совсем подходящий инструмент для вышеописанного. :)
>
> Нашел совсем недавно в 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.

>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>



-- 
Best regards, Ruslan.


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