?

Log in

No account? Create an account
Craftman

PEAR, как инструмент развертывания и распространения

У многих PHP программистов сложилось к PEAR довольно негативное отношение, как к большой, весьма разнородной библиотеке с весьма консервативной политикой. Однако кроме самих классов, PEAR представляет собой удобное средство управления установленными пакетами.

Когда пакет предназначен только для Вас самих, то часто для работы с ним достаточно только svn и rsync. Когда же вы предлагаете миру воспользоваться результатом Вашего труда, то оказывается, что миру не нужны ваши тесты, да и доступ в svn не очень-то нужен.

Можно написать скрипт, который из вашего полного репозитория соберет дистрибутив и запакует его. Однако обновления пользователю придется мониторить и ставить вручную.

PEAR дает возможность поднять у себя на сервере канал и предоставить пользователю работать с вашим пакетом следующим образом:

$ pear channel-discover mychannel.somehost.com

$ pear install mychannel/SomePackage
$ pear upgrade mychannel/SomePackage

Уже воспетое мною издательство продает книжку Greg Beaver, автора PEAR Server, обложку которой вы видите слева:
https://www.packtpub.com/PEAR-Installer

Ее же можно добыть у пиратов:
pdfchm.com/book/the-pear-installer-manifesto-6597

Статьи
Greg Beaver
Setting up your own PEAR channel with Chiara_PEAR_Server - the official way

Greg Beaver
Do you develop a website? It is infinitely better to synchronize live and development sites using the PEAR Installer

Greg Beaver
doing the PEAR thing

Tony Bibbs
HOWTO: Deploy Your Application Using PEAR

Павел Щеваев
Автоматизация проектных задач и организация Build->Package->Deploy цикла

Comments

Пир неплох, но ровно до того момента, когда тебе надо разобрать его на части или заменить часть поведения. После этого он ужасен.
Это ты про инсталлятор, менеджер пакетов и каналы или про сам набор классов? Классами я не пользуюсь.
про инсталлятор и менеджер пакетов. Каналы мы пока не пользуем.
а можно какой-нибудь пример? :)
Пример - необходимость подменить класс реджистри. Реджистри берется из конфига, но если включен packagingroot - инсталлятор создает реджистри через new.
Циклическая зависимость Config <-> Registry тоже не ахти.
Инсталлятор, который наследуюется от даунлоадера - в результате тащит кучу ненужной функциональности в себе (которую еще и приходится отключать).

Одним словом, PEAR оказался штукой довольно негибкой и порядком монолитной.

Сейчас собираемся Грегу писать - может учтет этот опыт в Пирусе.
Раз уж ты взялся делиться знанием, задам еще один вопрос:

Т.е. вы стали расширять и дополнять сам инсталлятор. А для чего возникла эта потребность? Чтобу выполнить какие-то пост-интсалляционные задачи после скачивания файлов?

В моем случае как-то всегда получается, что приложение содержит какие-то свои скрипты для работы с ним -- у Symfony есть Pake и файлы команд, с помощью которых можно развернуть и настроить.

Чтобу выполнить какие-то пост-интсалляционные задачи после скачивания файлов?

И это тоже - но не только. Честно говоря, сейчас уже с трудом помню конкретные резоны, были мысли расширять функциональность, поддерживать каскадирование обновлений по всей (многосайтовой/распределенной) системе, и т.д. Совершенно не подходила структура папок, на которой настаивал PEAR (разделение по ролям с общим корнем). Решили начать с замены системы хранения, косовато, но сделали. Ретроспективно это уже не кажется хорошим решением, ну да задним умом все крепки. Структуру папок тоже привели в нужный нам вид, добавили ролей, и т.п.

Впечатление от всего этого осталось крайне тяжелое, и не раз пожалели о том, что вообще заморочились с PEAR'ом. Он категорически сопротивляется любому использованию, как-либо отличному от того, для чего он предназначался изначально. У него фантастическая обратная совместимость - но это оборачивается тем, что приходится знать историю его развития (которую узнать можно лишь по cvs'у + архивы мейл-листов). Информации по внутреннему устройству катастрофически мало. Многие методы имеют крайне изменчивые сигнатуры (например три-пять опциональных параметров, каждый из может быть нескольких типов [массив, объект, строка, члены массива могут быть разных типов) и т.п.