Комментарии 29
Что сказать, молодцы, давно пора. Конечный юзер(программист) разницы особо и не заметит. Впрочем Composer не умеет печь блинчики, а моя бабушка умеет. Всем бабушку!
Хороший менеджер пакетов. Как раз занимаюсь его внедрением на работе.
Хм, почему-то считал, что PEAR уже давно скорее мертв чем жив и во всю пользуюсь Composer.
Composer и bower для меня такой же стандарт веб-разработки, как Git.
Жали только, что bower за собой всю NodeJS тянет. Приходится на паре машин держать этого монстра только для того, чтобы пакеты под PHP ставить :) Composer в этом смысле несравнимо изящнее, потому что автономный.
На девелопмент машине не страшно иметь NodeJS, даже наоборот полезно. Кофескрипт как плюшка идет. У меня и Руби для sass стоит)) А для продакшена просто храним под гитом пакеты.
То что Composer локально ставится, это да, большой плюс по сравнению с тем же bundler из ruby.
То что Composer локально ставится, это да, большой плюс по сравнению с тем же bundler из ruby.
Кстати, запоздалый комментарий. Появилась такая фишка, как bowerphp. Есть в Composer'е. Позволяет ставить bower-пакеты голым PHP. Так что NodeJS уже не так нужен :)
Жаль только в bower пакеты чаще всего с полными исходниками, не нужными для продакшна. Из-за этого сейчас стараюсь меньше использовать Bower, а делать «чистые» asset-пакеты для Composer. Хотя плохо, что в последнем нормального управления asset'ами пока нет. Есть пара расширений на этот счёт, но они не идеальны :)
Жаль только в bower пакеты чаще всего с полными исходниками, не нужными для продакшна. Из-за этого сейчас стараюсь меньше использовать Bower, а делать «чистые» asset-пакеты для Composer. Хотя плохо, что в последнем нормального управления asset'ами пока нет. Есть пара расширений на этот счёт, но они не идеальны :)
не знаю у кого как, а у меня на РНР 5.3 использование Композера на ВПС невозможно ввиду того, что даже 512 МБ ОП ему мало.
У меня на виртуалке домашнего компа Debian 512 MB ОЗУ, все летает.
Запускайте через php -d memory_limit=-1 composer…
Был такой глюк на PHP 5.3, что компосер падал в память. Хотя все поправили уже давно. Может вы не обновились?
З.Ы. Памяти ему хватит и 128Мб
Был такой глюк на PHP 5.3, что компосер падал в память. Хотя все поправили уже давно. Может вы не обновились?
З.Ы. Памяти ему хватит и 128Мб
я обновляю композер постоянно. Вот только что попробовал на ВПС с 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ГБ — тогда работает. Но я считаю это странной ситуацией.
VPS на OpenVZ?
ulimit -s 1024
С PEAR всегда были какие-то проблемы — он постоянно устанавливался как-то с проблемами, но имел положительное качество: после установки просто появлялась библиотека как в Java зависимость. С Composer в свое время терпели постоянно неудачи, так как старая иерархия папок и старый подход не позволял интегрировать Composer. Я не знаю возможно ли сегодня использовать Composer как просто установщик пакетов как PEAR и не делать никаких гадких изменений в vendor,php и т.п. Кроме того по прежнему нет инфраструктуру для PHP, а именно систем ContinusIntegration и систем развертывания.
UPD: вроде рассказали про Phar, но я не пользовался.
UPD: вроде рассказали про Phar, но я не пользовался.
Именно для PHP есть как минимум PHPCI, который composer поддерживает из коробки
Написал небольшой пост с обзором PHPCI по случаю.
>> С 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.
>> С Composer в свое время терпели постоянно неудачи, так как старая иерархия папок и старый подход не позволял интегрировать
>> А в чем там проблема?
Сейчас мне сложно вспомнить, но как-раз автоматическое создание каталога с библиотеками и поддержка автоматической загрузки создавало с чем-то конфликт. Даже думали писать свой расширение для установки для Composer, но потом отказались вообще от Composer, так как на тот момент это было долго и коммерческая выгода не была очевидна.
> Вендоры можно устанавливать в любую папку
Ну хотелось бы что бы они ставились как PEAR в папку общую для всего PHP по умолчанию. Таким образом частный случай будет делать так называемый VirtualEnv, что многим нужно, а многим нет.
> CI мы не используем, но с ходу нагуглил, например, PHPCI
Я так думаю, что это очень новый продукт. так как года два назад я его не нашел.
> Какие именно системы развертывания вы имеете в виду?
На тот момент идельно подходил ANT, но опять таки зависимость от JAVA появлялась.
Типичные же задачи скачать что-то положить куда-то. Создать папку и запустить какой-то сценарий. Импортировать базу подождать немного… Удалить кеши. Перезапустить APACHE. Ну вот какие-то такие действия…
>> А в чем там проблема?
Сейчас мне сложно вспомнить, но как-раз автоматическое создание каталога с библиотеками и поддержка автоматической загрузки создавало с чем-то конфликт. Даже думали писать свой расширение для установки для Composer, но потом отказались вообще от Composer, так как на тот момент это было долго и коммерческая выгода не была очевидна.
> Вендоры можно устанавливать в любую папку
Ну хотелось бы что бы они ставились как PEAR в папку общую для всего PHP по умолчанию. Таким образом частный случай будет делать так называемый VirtualEnv, что многим нужно, а многим нет.
> CI мы не используем, но с ходу нагуглил, например, PHPCI
Я так думаю, что это очень новый продукт. так как года два назад я его не нашел.
> Какие именно системы развертывания вы имеете в виду?
На тот момент идельно подходил ANT, но опять таки зависимость от JAVA появлялась.
Типичные же задачи скачать что-то положить куда-то. Создать папку и запустить какой-то сценарий. Импортировать базу подождать немного… Удалить кеши. Перезапустить APACHE. Ну вот какие-то такие действия…
Для развертывания можно было и Phing использовать, все тоже самое что у Ant-а есть, зато нет зависимости от Java. Phing вроде довольно старый инструмент, старше 2х лет точно.
Phing мне попался уже после того как все было сделано на ANT.
Одним словом очень грустно, что инструменты для PHP на столько поздно ко мне попали в руки и были на тот момент не очень популярны (А сейчас хотелось бы узнать у разработчиков на сколько они стали популярными? Используете ли Вы их?)
Хорошо было бы иметь какие-то эталоны, то есть стандартные хорошие практики для новых команд и стартапов (Если у кого-то есть хорошие истории поделитесь. Заранее благодарен.)
А для небольших компаний это могло бы стать примером для подражания и вектором развития. Так как я в свое время набил очень много коленок(В том числе и сейчас часто выполняю частичный деплой через sftp) на том что бы начать использовать штатные и стандартные инструменты: развертывания, и т.д.
Одним словом очень грустно, что инструменты для PHP на столько поздно ко мне попали в руки и были на тот момент не очень популярны (А сейчас хотелось бы узнать у разработчиков на сколько они стали популярными? Используете ли Вы их?)
Хорошо было бы иметь какие-то эталоны, то есть стандартные хорошие практики для новых команд и стартапов (Если у кого-то есть хорошие истории поделитесь. Заранее благодарен.)
А для небольших компаний это могло бы стать примером для подражания и вектором развития. Так как я в свое время набил очень много коленок(В том числе и сейчас часто выполняю частичный деплой через sftp) на том что бы начать использовать штатные и стандартные инструменты: развертывания, и т.д.
Ну Phing вполне себе популярен, во всяком случае для крупных проектов. Мне лично он не очень нравится, как раз своей схожестью с java-инструментами вроде Antа (XML-конфигурация), но по работе попадалитсь проекты, где он уже во всю использовался неоднократно.
Сейчас есть и другие более молодые PHP-инструменты для деплоя вроде Rocketeer, сам я его не использовал, но судя по документации выглядит вкусно.
Сейчас есть и другие более молодые PHP-инструменты для деплоя вроде Rocketeer, сам я его не использовал, но судя по документации выглядит вкусно.
После опыта с Phing перешёл на Robo — красота, никаких конфигов в XML, легко расширяется, активно разрабатывается.
>> Ну хотелось бы что бы они ставились как PEAR в папку общую для всего PHP по умолчанию
Мне всегда казалось, что это очень плохо мешать все в одну кучу. Во-первых, непонятно, каким образом узнать, какие вендоры уже не нужны. Во-вторых, при деплое очень важно на каждый билд иметь свой набор вендоров, чтобы работа сайта не останавливалась ни на секунду.
>> Типичные же задачи скачать что-то положить куда-то. Создать папку и запустить какой-то сценарий. Импортировать базу подождать немного… Удалить кеши. Перезапустить APACHE. Ну вот какие-то такие действия…
Тогда вам нужен Capistrano либо Rocketeer. Полностью в автоматизированном виде одной командой по ssh деплоят приложение на сервер, код могут забирать с любой системы контроля версий, по пути можно выполнять любые шел-команды. Одной же командой можно и откатиться, если что не так. Сам пользуюсь Capistrano, но для него надо руби ставить (только на девелопмент машине). Rocketeer полностью PHP, но мне как-то неохота было с ним разбираться, т.к. Capistrano устраивает.
Мне всегда казалось, что это очень плохо мешать все в одну кучу. Во-первых, непонятно, каким образом узнать, какие вендоры уже не нужны. Во-вторых, при деплое очень важно на каждый билд иметь свой набор вендоров, чтобы работа сайта не останавливалась ни на секунду.
>> Типичные же задачи скачать что-то положить куда-то. Создать папку и запустить какой-то сценарий. Импортировать базу подождать немного… Удалить кеши. Перезапустить APACHE. Ну вот какие-то такие действия…
Тогда вам нужен Capistrano либо Rocketeer. Полностью в автоматизированном виде одной командой по ssh деплоят приложение на сервер, код могут забирать с любой системы контроля версий, по пути можно выполнять любые шел-команды. Одной же командой можно и откатиться, если что не так. Сам пользуюсь Capistrano, но для него надо руби ставить (только на девелопмент машине). Rocketeer полностью PHP, но мне как-то неохота было с ним разбираться, т.к. Capistrano устраивает.
> Тогда вам нужен Capistrano либо Rocketeer. Полностью в автоматизированном виде одной командой по ssh деплоят приложение на сервер, код могут забирать с любой системы контроля версий, по пути можно выполнять любые шел-команды. Одной же командой можно и откатиться, если что не так. Сам пользуюсь Capistrano, но для него надо руби ставить (только на девелопмент машине)
Опять возвращаемся к проблеме чем инструмент на Ruby лучше чем инструмент на Java. Дополнительная зависиомость. А кроме того у меня нет доступа к SSH это продакшен сервера и они должны обновляться из пакета обновления, так что тут только ANT может подойти или вообще поставлять продукт в виде PHAR интересно как там с производительностью чтения в PHAR? Автодеплой тогда сильно может упроститься при использовании PHAR.
Вообщем все это обходные пути (workaround) для нерешенных задач и не продуманных разработчиками PHP пока ситуаций. Ждем улучшения ситуации и новых удобных инструментов.
Опять возвращаемся к проблеме чем инструмент на Ruby лучше чем инструмент на Java. Дополнительная зависиомость. А кроме того у меня нет доступа к SSH это продакшен сервера и они должны обновляться из пакета обновления, так что тут только ANT может подойти или вообще поставлять продукт в виде PHAR интересно как там с производительностью чтения в PHAR? Автодеплой тогда сильно может упроститься при использовании PHAR.
Вообщем все это обходные пути (workaround) для нерешенных задач и не продуманных разработчиками PHP пока ситуаций. Ждем улучшения ситуации и новых удобных инструментов.
Уже года полтора-два пользуюсь только комозером, очень удобно. Была в свое время тоже проблема с нехваткой оперативной памяти на VPS, но сейчас сервер по-мощнее, поэтому уже давно забыл про это. С PEAR-ом как-то изначально не сложилось, серьезно не пользовался им никогда, вся охота отпадала где-то в процессе чтения документации.
Интересно, что будет с pecl, ведь он использует пакетную систему pear, ставится вместе с pear и тп?
Понятно, что от расширений никто отказываться не собирается и соответственно, все по-прежнему будут ставить pear, но использовать только pecl.
Понятно, что от расширений никто отказываться не собирается и соответственно, все по-прежнему будут ставить pear, но использовать только pecl.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Расцвет Composer и закат PEAR