8 мая 2014 в 07:08

Расцвет Composer и закат 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!
Автор оригинала: Fabien Potencier
Владимир Болиев @voff
карма
112,2
рейтинг 0,0
PHP

Комментарии (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.

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