Comments 29
Что сказать, молодцы, давно пора. Конечный юзер(программист) разницы особо и не заметит. Впрочем Composer не умеет печь блинчики, а моя бабушка умеет. Всем бабушку!
+11
Хороший менеджер пакетов. Как раз занимаюсь его внедрением на работе.
+1
Хм, почему-то считал, что PEAR уже давно скорее мертв чем жив и во всю пользуюсь Composer.
+8
Composer и bower для меня такой же стандарт веб-разработки, как Git.
0
Жали только, что bower за собой всю NodeJS тянет. Приходится на паре машин держать этого монстра только для того, чтобы пакеты под PHP ставить :) Composer в этом смысле несравнимо изящнее, потому что автономный.
0
На девелопмент машине не страшно иметь NodeJS, даже наоборот полезно. Кофескрипт как плюшка идет. У меня и Руби для sass стоит)) А для продакшена просто храним под гитом пакеты.
То что Composer локально ставится, это да, большой плюс по сравнению с тем же bundler из ruby.
То что Composer локально ставится, это да, большой плюс по сравнению с тем же bundler из ruby.
+1
Кстати, запоздалый комментарий. Появилась такая фишка, как bowerphp. Есть в Composer'е. Позволяет ставить bower-пакеты голым PHP. Так что NodeJS уже не так нужен :)
Жаль только в bower пакеты чаще всего с полными исходниками, не нужными для продакшна. Из-за этого сейчас стараюсь меньше использовать Bower, а делать «чистые» asset-пакеты для Composer. Хотя плохо, что в последнем нормального управления asset'ами пока нет. Есть пара расширений на этот счёт, но они не идеальны :)
Жаль только в bower пакеты чаще всего с полными исходниками, не нужными для продакшна. Из-за этого сейчас стараюсь меньше использовать Bower, а делать «чистые» asset-пакеты для Composer. Хотя плохо, что в последнем нормального управления asset'ами пока нет. Есть пара расширений на этот счёт, но они не идеальны :)
0
не знаю у кого как, а у меня на РНР 5.3 использование Композера на ВПС невозможно ввиду того, что даже 512 МБ ОП ему мало.
+1
У меня на виртуалке домашнего компа Debian 512 MB ОЗУ, все летает.
0
Запускайте через php -d memory_limit=-1 composer…
Был такой глюк на PHP 5.3, что компосер падал в память. Хотя все поправили уже давно. Может вы не обновились?
З.Ы. Памяти ему хватит и 128Мб
Был такой глюк на 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ГБ — тогда работает. Но я считаю это странной ситуацией.
$ composer.phar update
Loading composer repositories with package information
Updating dependencies (including require-dev)
Killed
Exit 137
Я запускаю на десктопе с лимитом по памяти для РНР 1ГБ — тогда работает. Но я считаю это странной ситуацией.
0
VPS на OpenVZ?
ulimit -s 1024
0
С PEAR всегда были какие-то проблемы — он постоянно устанавливался как-то с проблемами, но имел положительное качество: после установки просто появлялась библиотека как в Java зависимость. С Composer в свое время терпели постоянно неудачи, так как старая иерархия папок и старый подход не позволял интегрировать Composer. Я не знаю возможно ли сегодня использовать Composer как просто установщик пакетов как PEAR и не делать никаких гадких изменений в vendor,php и т.п. Кроме того по прежнему нет инфраструктуру для PHP, а именно систем ContinusIntegration и систем развертывания.
UPD: вроде рассказали про Phar, но я не пользовался.
UPD: вроде рассказали про Phar, но я не пользовался.
0
Именно для PHP есть как минимум PHPCI, который composer поддерживает из коробки
0
Написал небольшой пост с обзором PHPCI по случаю.
0
>> С Composer в свое время терпели постоянно неудачи, так как старая иерархия папок и старый подход не позволял интегрировать Composer
А в чем там проблема?
>> Я не знаю возможно ли сегодня использовать Composer как просто установщик пакетов как PEAR и не делать никаких гадких изменений в vendor,php и т.п.
Вендоры можно устанавливать в любую папку. В php composer никаких изменений не делает.
>> Кроме того по прежнему нет инфраструктуру для PHP, а именно систем ContinusIntegration и систем развертывания.
CI мы не используем, но с ходу нагуглил, например, PHPCI. Какие именно системы развертывания вы имеете в виду? Деплой capistrano/rocketeer, окружение chef/puppet/vagrant, фронтенд grunt/gulp.
А в чем там проблема?
>> Я не знаю возможно ли сегодня использовать 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. Ну вот какие-то такие действия…
>> А в чем там проблема?
Сейчас мне сложно вспомнить, но как-раз автоматическое создание каталога с библиотеками и поддержка автоматической загрузки создавало с чем-то конфликт. Даже думали писать свой расширение для установки для Composer, но потом отказались вообще от Composer, так как на тот момент это было долго и коммерческая выгода не была очевидна.
> Вендоры можно устанавливать в любую папку
Ну хотелось бы что бы они ставились как PEAR в папку общую для всего PHP по умолчанию. Таким образом частный случай будет делать так называемый VirtualEnv, что многим нужно, а многим нет.
> CI мы не используем, но с ходу нагуглил, например, PHPCI
Я так думаю, что это очень новый продукт. так как года два назад я его не нашел.
> Какие именно системы развертывания вы имеете в виду?
На тот момент идельно подходил ANT, но опять таки зависимость от JAVA появлялась.
Типичные же задачи скачать что-то положить куда-то. Создать папку и запустить какой-то сценарий. Импортировать базу подождать немного… Удалить кеши. Перезапустить APACHE. Ну вот какие-то такие действия…
0
Для развертывания можно было и Phing использовать, все тоже самое что у Ant-а есть, зато нет зависимости от Java. Phing вроде довольно старый инструмент, старше 2х лет точно.
0
Phing мне попался уже после того как все было сделано на ANT.
Одним словом очень грустно, что инструменты для PHP на столько поздно ко мне попали в руки и были на тот момент не очень популярны (А сейчас хотелось бы узнать у разработчиков на сколько они стали популярными? Используете ли Вы их?)
Хорошо было бы иметь какие-то эталоны, то есть стандартные хорошие практики для новых команд и стартапов (Если у кого-то есть хорошие истории поделитесь. Заранее благодарен.)
А для небольших компаний это могло бы стать примером для подражания и вектором развития. Так как я в свое время набил очень много коленок(В том числе и сейчас часто выполняю частичный деплой через sftp) на том что бы начать использовать штатные и стандартные инструменты: развертывания, и т.д.
Одним словом очень грустно, что инструменты для PHP на столько поздно ко мне попали в руки и были на тот момент не очень популярны (А сейчас хотелось бы узнать у разработчиков на сколько они стали популярными? Используете ли Вы их?)
Хорошо было бы иметь какие-то эталоны, то есть стандартные хорошие практики для новых команд и стартапов (Если у кого-то есть хорошие истории поделитесь. Заранее благодарен.)
А для небольших компаний это могло бы стать примером для подражания и вектором развития. Так как я в свое время набил очень много коленок(В том числе и сейчас часто выполняю частичный деплой через sftp) на том что бы начать использовать штатные и стандартные инструменты: развертывания, и т.д.
0
Ну Phing вполне себе популярен, во всяком случае для крупных проектов. Мне лично он не очень нравится, как раз своей схожестью с java-инструментами вроде Antа (XML-конфигурация), но по работе попадалитсь проекты, где он уже во всю использовался неоднократно.
Сейчас есть и другие более молодые PHP-инструменты для деплоя вроде Rocketeer, сам я его не использовал, но судя по документации выглядит вкусно.
Сейчас есть и другие более молодые PHP-инструменты для деплоя вроде Rocketeer, сам я его не использовал, но судя по документации выглядит вкусно.
0
После опыта с Phing перешёл на Robo — красота, никаких конфигов в XML, легко расширяется, активно разрабатывается.
0
>> Ну хотелось бы что бы они ставились как PEAR в папку общую для всего PHP по умолчанию
Мне всегда казалось, что это очень плохо мешать все в одну кучу. Во-первых, непонятно, каким образом узнать, какие вендоры уже не нужны. Во-вторых, при деплое очень важно на каждый билд иметь свой набор вендоров, чтобы работа сайта не останавливалась ни на секунду.
>> Типичные же задачи скачать что-то положить куда-то. Создать папку и запустить какой-то сценарий. Импортировать базу подождать немного… Удалить кеши. Перезапустить APACHE. Ну вот какие-то такие действия…
Тогда вам нужен Capistrano либо Rocketeer. Полностью в автоматизированном виде одной командой по ssh деплоят приложение на сервер, код могут забирать с любой системы контроля версий, по пути можно выполнять любые шел-команды. Одной же командой можно и откатиться, если что не так. Сам пользуюсь Capistrano, но для него надо руби ставить (только на девелопмент машине). Rocketeer полностью PHP, но мне как-то неохота было с ним разбираться, т.к. Capistrano устраивает.
Мне всегда казалось, что это очень плохо мешать все в одну кучу. Во-первых, непонятно, каким образом узнать, какие вендоры уже не нужны. Во-вторых, при деплое очень важно на каждый билд иметь свой набор вендоров, чтобы работа сайта не останавливалась ни на секунду.
>> Типичные же задачи скачать что-то положить куда-то. Создать папку и запустить какой-то сценарий. Импортировать базу подождать немного… Удалить кеши. Перезапустить APACHE. Ну вот какие-то такие действия…
Тогда вам нужен Capistrano либо Rocketeer. Полностью в автоматизированном виде одной командой по ssh деплоят приложение на сервер, код могут забирать с любой системы контроля версий, по пути можно выполнять любые шел-команды. Одной же командой можно и откатиться, если что не так. Сам пользуюсь Capistrano, но для него надо руби ставить (только на девелопмент машине). Rocketeer полностью PHP, но мне как-то неохота было с ним разбираться, т.к. Capistrano устраивает.
0
> Тогда вам нужен Capistrano либо Rocketeer. Полностью в автоматизированном виде одной командой по ssh деплоят приложение на сервер, код могут забирать с любой системы контроля версий, по пути можно выполнять любые шел-команды. Одной же командой можно и откатиться, если что не так. Сам пользуюсь Capistrano, но для него надо руби ставить (только на девелопмент машине)
Опять возвращаемся к проблеме чем инструмент на Ruby лучше чем инструмент на Java. Дополнительная зависиомость. А кроме того у меня нет доступа к SSH это продакшен сервера и они должны обновляться из пакета обновления, так что тут только ANT может подойти или вообще поставлять продукт в виде PHAR интересно как там с производительностью чтения в PHAR? Автодеплой тогда сильно может упроститься при использовании PHAR.
Вообщем все это обходные пути (workaround) для нерешенных задач и не продуманных разработчиками PHP пока ситуаций. Ждем улучшения ситуации и новых удобных инструментов.
Опять возвращаемся к проблеме чем инструмент на Ruby лучше чем инструмент на Java. Дополнительная зависиомость. А кроме того у меня нет доступа к SSH это продакшен сервера и они должны обновляться из пакета обновления, так что тут только ANT может подойти или вообще поставлять продукт в виде PHAR интересно как там с производительностью чтения в PHAR? Автодеплой тогда сильно может упроститься при использовании PHAR.
Вообщем все это обходные пути (workaround) для нерешенных задач и не продуманных разработчиками PHP пока ситуаций. Ждем улучшения ситуации и новых удобных инструментов.
0
Уже года полтора-два пользуюсь только комозером, очень удобно. Была в свое время тоже проблема с нехваткой оперативной памяти на VPS, но сейчас сервер по-мощнее, поэтому уже давно забыл про это. С PEAR-ом как-то изначально не сложилось, серьезно не пользовался им никогда, вся охота отпадала где-то в процессе чтения документации.
0
Интересно, что будет с pecl, ведь он использует пакетную систему pear, ставится вместе с pear и тп?
Понятно, что от расширений никто отказываться не собирается и соответственно, все по-прежнему будут ставить pear, но использовать только pecl.
Понятно, что от расширений никто отказываться не собирается и соответственно, все по-прежнему будут ставить pear, но использовать только pecl.
0
Sign up to leave a comment.
Расцвет Composer и закат PEAR