Расцвет Composer и закат PEAR

http://fabien.potencier.org/article/72/the-rise-of-composer-and-the-fall-of-pear
  • Перевод
[Дабы не возникло недопонимания, стоит пояснить, что автор оригинального текста — Fabien Potencier, создатель популярного PHP фреймворка Symfony — прим. пер.]

Совсем недавно, Nils Adermann, прислал мне милую открытку, в напоминание о нашей встречи три года назад на “SymfonyLive hackday” в Сан-Франциско. Nils присутствовал на конференции, т.к. за год до этого, он анонсировал, что phpBB в версии 4 перейдет на Symfony.

В то время, я серьезно интересовался темой менеджеров пакетов, ибо искал удобный способ управлять бандлами в Symfony2. Для плагинов в Symfony1 я использовал PEAR, но код был очень запутанным, ведь PEAR изначально создавался немного не для этого. Философия Бандлера из Ruby сообщества выглядела очень привлекательно, так что я начал поиски подобного пакетного менеджера. После долгих бессонных ночей, я наткнулся на libzypp, и моментально понял, что это оно! К сожалению libzypp — сложная библиотека, написанная на C, и в таком виде, совсем не подходила для Symfony.

Я смекнул, что хорошим менеджером пакетов, позволяющим пользователям легко устанавливать плагины/бандлы/моды наверняка интересуется и Nils, для phpBB, так что я завел об этом разговор на hackday в Сан-Франциско. Оказалось, что в то время, Нилс уже начал работу над Composer.

Нилс проделал потрясающую работу по переводу C кода в PHP код. Позже, присоединившийся к команде Джорди вывел все на новый уровень, взяв на себя заботы по реализации всей инфраструктуры проекта.

Так, что насчет PEAR? PEAR верой и правдой служил PHP сообществу много лет, думаю настало время, дать ему умереть.

Я использовал PEAR в качестве менеджера пакетов еще с моего первого проекта на PHP в далеком 2004-м. Я даже написал популярный сервер каналов Pirum. Но сейчас настало время двигаться дальше, и рассказать о своих планах на каналы, которыми я управляю.

13 февраля я писал в твиттере, что собираюсь перестать поддерживать свои пакеты в PEAR, т.к. Composer уже достаточно популярен. 14 февраля я решил перестать работать над Pirum.

Так как многие хотели узнать статистику канала Symfony, я залез в логи, и обнаружил, что большинство запросов идет от зависимостей PHPUnit. 20-того апреля Sebastian Bergmann открыл обсуждение о поддержке PEAR для PHPUnit. На следующий день, он опубликовал сообщение, в котором прощался с PEAR. Чуть позже, Pádraic Brady также отказался от поддержки PEAR канала для Mockery.

Кроме Symfony, в моем ведении также находятся каналы Twig, Swiftmailer и Pirum. И вот мои планы:

  • Обновить документацию, четко объяснить в ней, что каналы PEAR устарели, и что предпочитаемый менеджер пакетов — Composer. (Уже сделано для всех проектов).
  • Опубликовать заметку об устаревании PEAR каналов на сайтах этих каналов (сделано для всех проектов)
  • Опубликовать пост в блогах (Twig, Swiftmailer и Symfony)
  • Перестать выпускать новые PEAR пакеты
  • Удалить описание установки через PEAR в официальной документации (Вероятно в сентябре этого года)


Заметьте, что я говорю о прекращении выпуска НОВЫХ пакетов в PEAR, и продвижении Composer как основного средства для инсталляции моих библиотек и проектов. Уже существующие пакеты, в обозримом будущем, все еще можно будет ставить через PEAR.

Всем Composer!
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 29
  • +11
    Что сказать, молодцы, давно пора. Конечный юзер(программист) разницы особо и не заметит. Впрочем Composer не умеет печь блинчики, а моя бабушка умеет. Всем бабушку!
    • +1
      Хороший менеджер пакетов. Как раз занимаюсь его внедрением на работе.
      • +8
        Хм, почему-то считал, что PEAR уже давно скорее мертв чем жив и во всю пользуюсь Composer.
        • 0
          Composer и bower для меня такой же стандарт веб-разработки, как Git.
          • 0
            Жали только, что bower за собой всю NodeJS тянет. Приходится на паре машин держать этого монстра только для того, чтобы пакеты под PHP ставить :) Composer в этом смысле несравнимо изящнее, потому что автономный.
            • +1
              На девелопмент машине не страшно иметь NodeJS, даже наоборот полезно. Кофескрипт как плюшка идет. У меня и Руби для sass стоит)) А для продакшена просто храним под гитом пакеты.
              То что Composer локально ставится, это да, большой плюс по сравнению с тем же bundler из ruby.
              • 0
                Кстати, запоздалый комментарий. Появилась такая фишка, как bowerphp. Есть в Composer'е. Позволяет ставить bower-пакеты голым PHP. Так что NodeJS уже не так нужен :)

                Жаль только в bower пакеты чаще всего с полными исходниками, не нужными для продакшна. Из-за этого сейчас стараюсь меньше использовать Bower, а делать «чистые» asset-пакеты для Composer. Хотя плохо, что в последнем нормального управления asset'ами пока нет. Есть пара расширений на этот счёт, но они не идеальны :)
                • 0
                  >> Появилась такая фишка, как bowerphp

                  Да, видели, знаем, даже используем. Но сыроват еще пока. К примеру не работает указание репозитория в качестве пакета.
        • +1
          не знаю у кого как, а у меня на РНР 5.3 использование Композера на ВПС невозможно ввиду того, что даже 512 МБ ОП ему мало.
          • 0
            У меня на виртуалке домашнего компа Debian 512 MB ОЗУ, все летает.
            • 0
              Запускайте через php -d memory_limit=-1 composer…
              Был такой глюк на PHP 5.3, что компосер падал в память. Хотя все поправили уже давно. Может вы не обновились?
              З.Ы. Памяти ему хватит и 128Мб
              • 0
                я обновляю композер постоянно. Вот только что попробовал на ВПС с 512 МБ памяти с memory_limit = -1:

                $ composer.phar update
                Loading composer repositories with package information
                Updating dependencies (including require-dev)
                Killed
                Exit 137

                Я запускаю на десктопе с лимитом по памяти для РНР 1ГБ — тогда работает. Но я считаю это странной ситуацией.
                • 0
                  Странно. Одно время (но не долго) использовал Composer именно на VPS с 512Мб (DigitalOcean). Но потом до 1Гб расширил, MySQL базы не маленькие нужны.

                  И лимит памяти для PHP в cli на машинах стоит часто 128 или 256Мб — хватает.
              • 0
                VPS на OpenVZ?
                ulimit -s 1024
              • 0
                С PEAR всегда были какие-то проблемы — он постоянно устанавливался как-то с проблемами, но имел положительное качество: после установки просто появлялась библиотека как в Java зависимость. С Composer в свое время терпели постоянно неудачи, так как старая иерархия папок и старый подход не позволял интегрировать Composer. Я не знаю возможно ли сегодня использовать Composer как просто установщик пакетов как PEAR и не делать никаких гадких изменений в vendor,php и т.п. Кроме того по прежнему нет инфраструктуру для PHP, а именно систем ContinusIntegration и систем развертывания.

                UPD: вроде рассказали про Phar, но я не пользовался.
                • 0
                  Именно для PHP есть как минимум PHPCI, который composer поддерживает из коробки
                  • 0
                    Написал небольшой пост с обзором PHPCI по случаю.
                    • 0
                      Просто великолепно! Только как-то дорого у них там все, а так очень хорошо, что есть такой инструмент.
                      • 0
                        Ну никто не мешает развернуть у себя на сервере)
                  • 0
                    >> С Composer в свое время терпели постоянно неудачи, так как старая иерархия папок и старый подход не позволял интегрировать Composer

                    А в чем там проблема?

                    >> Я не знаю возможно ли сегодня использовать Composer как просто установщик пакетов как PEAR и не делать никаких гадких изменений в vendor,php и т.п.

                    Вендоры можно устанавливать в любую папку. В php composer никаких изменений не делает.

                    >> Кроме того по прежнему нет инфраструктуру для PHP, а именно систем ContinusIntegration и систем развертывания.

                    CI мы не используем, но с ходу нагуглил, например, PHPCI. Какие именно системы развертывания вы имеете в виду? Деплой capistrano/rocketeer, окружение chef/puppet/vagrant, фронтенд grunt/gulp.
                    • 0
                      >> С Composer в свое время терпели постоянно неудачи, так как старая иерархия папок и старый подход не позволял интегрировать
                      >> А в чем там проблема?
                      Сейчас мне сложно вспомнить, но как-раз автоматическое создание каталога с библиотеками и поддержка автоматической загрузки создавало с чем-то конфликт. Даже думали писать свой расширение для установки для Composer, но потом отказались вообще от Composer, так как на тот момент это было долго и коммерческая выгода не была очевидна.

                      > Вендоры можно устанавливать в любую папку
                      Ну хотелось бы что бы они ставились как PEAR в папку общую для всего PHP по умолчанию. Таким образом частный случай будет делать так называемый VirtualEnv, что многим нужно, а многим нет.

                      > CI мы не используем, но с ходу нагуглил, например, PHPCI
                      Я так думаю, что это очень новый продукт. так как года два назад я его не нашел.

                      > Какие именно системы развертывания вы имеете в виду?
                      На тот момент идельно подходил ANT, но опять таки зависимость от JAVA появлялась.
                      Типичные же задачи скачать что-то положить куда-то. Создать папку и запустить какой-то сценарий. Импортировать базу подождать немного… Удалить кеши. Перезапустить APACHE. Ну вот какие-то такие действия…
                      • 0
                        Для развертывания можно было и Phing использовать, все тоже самое что у Ant-а есть, зато нет зависимости от Java. Phing вроде довольно старый инструмент, старше 2х лет точно.
                        • 0
                          Phing мне попался уже после того как все было сделано на ANT.

                          Одним словом очень грустно, что инструменты для PHP на столько поздно ко мне попали в руки и были на тот момент не очень популярны (А сейчас хотелось бы узнать у разработчиков на сколько они стали популярными? Используете ли Вы их?)

                          Хорошо было бы иметь какие-то эталоны, то есть стандартные хорошие практики для новых команд и стартапов (Если у кого-то есть хорошие истории поделитесь. Заранее благодарен.)

                          А для небольших компаний это могло бы стать примером для подражания и вектором развития. Так как я в свое время набил очень много коленок(В том числе и сейчас часто выполняю частичный деплой через sftp) на том что бы начать использовать штатные и стандартные инструменты: развертывания, и т.д.
                          • 0
                            Ну Phing вполне себе популярен, во всяком случае для крупных проектов. Мне лично он не очень нравится, как раз своей схожестью с java-инструментами вроде Antа (XML-конфигурация), но по работе попадалитсь проекты, где он уже во всю использовался неоднократно.

                            Сейчас есть и другие более молодые PHP-инструменты для деплоя вроде Rocketeer, сам я его не использовал, но судя по документации выглядит вкусно.
                            • 0
                              После опыта с Phing перешёл на Robo — красота, никаких конфигов в XML, легко расширяется, активно разрабатывается.
                          • 0
                            >> Ну хотелось бы что бы они ставились как PEAR в папку общую для всего PHP по умолчанию

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

                            >> Типичные же задачи скачать что-то положить куда-то. Создать папку и запустить какой-то сценарий. Импортировать базу подождать немного… Удалить кеши. Перезапустить APACHE. Ну вот какие-то такие действия…

                            Тогда вам нужен Capistrano либо Rocketeer. Полностью в автоматизированном виде одной командой по ssh деплоят приложение на сервер, код могут забирать с любой системы контроля версий, по пути можно выполнять любые шел-команды. Одной же командой можно и откатиться, если что не так. Сам пользуюсь Capistrano, но для него надо руби ставить (только на девелопмент машине). Rocketeer полностью PHP, но мне как-то неохота было с ним разбираться, т.к. Capistrano устраивает.
                            • 0
                              > Тогда вам нужен Capistrano либо Rocketeer. Полностью в автоматизированном виде одной командой по ssh деплоят приложение на сервер, код могут забирать с любой системы контроля версий, по пути можно выполнять любые шел-команды. Одной же командой можно и откатиться, если что не так. Сам пользуюсь Capistrano, но для него надо руби ставить (только на девелопмент машине)

                              Опять возвращаемся к проблеме чем инструмент на Ruby лучше чем инструмент на Java. Дополнительная зависиомость. А кроме того у меня нет доступа к SSH это продакшен сервера и они должны обновляться из пакета обновления, так что тут только ANT может подойти или вообще поставлять продукт в виде PHAR интересно как там с производительностью чтения в PHAR? Автодеплой тогда сильно может упроститься при использовании PHAR.

                              Вообщем все это обходные пути (workaround) для нерешенных задач и не продуманных разработчиками PHP пока ситуаций. Ждем улучшения ситуации и новых удобных инструментов.
                        • 0
                          Уже года полтора-два пользуюсь только комозером, очень удобно. Была в свое время тоже проблема с нехваткой оперативной памяти на VPS, но сейчас сервер по-мощнее, поэтому уже давно забыл про это. С PEAR-ом как-то изначально не сложилось, серьезно не пользовался им никогда, вся охота отпадала где-то в процессе чтения документации.
                          • 0
                            Интересно, что будет с pecl, ведь он использует пакетную систему pear, ставится вместе с pear и тп?

                            Понятно, что от расширений никто отказываться не собирается и соответственно, все по-прежнему будут ставить pear, но использовать только pecl.

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.