Composer — средство управления зависимостями

[Balancer]

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

Подумываю, не начать ли растаскивать по нему свой фреймворк.

Никто не поделится опытом использования Composer? Плюсы, минусы, подводные камни, надёжность на практике?

 

[Ragazzo]

Balancer
Подводный камень один - они еще далеки до стабильного нормального билда, можно посмотреть по issue и ПР на гитхабе. разбирался с ним делаю, модуль обновлений/установки, но то что в нем еще много косяков немного напрягает.

 

[Balancer]

А как у Composer загрузчик классов со своими загрузчиками совмещается?

Я в тестах навскидку не смог добиться совместимости загрузчика от Composer и своего (тоже SPL). К счастью, у меня система именований классов в проектах оказалась совместимой с PSR-0 (хотя и рождалась лет 8..9 назад), так что пока голову ломать не стал и задействовал загрузчик Composer'а. Но он гарантирует работоспособность не в 100% случаев, скажем, у меня классы с одним префиксом могут лежать в разных репозиториях.

Так что вопрос, это я чего-то недоработал в грубых тестах, или autoloader у Composer'а несовместим со сторонними?

 

[AmdY]

Balancer
всё прекрасно, однозначто стоит юзать. я свой загрузчик классов полностью выбросил, заменив его на поставляемый с компосером (там symfony компонент вроде)

namespace Frm;
require 'vendor/autoload.php';
(new Bootstrap())
    ->run();

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

 

[Ragazzo]

Да, насколько я знаю composer же использует в качестве автолоада имена в psr-0.
AmdY composer в symfony встроен?О_о

 

[AmdY]

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

 

[MiksIr]

Это что-то типа gem-ов получается?

 

[AmdY]

MiksIr
некоторые утверждают что даже лучше, но это сомнительно. документация полное гавно, чтобы реально прицениться, я в закрытых тикетах копался, чтобы понять тупо как подгружать jquery.

 

[Absinthe]

Я не стану его использовать до тех пор, пока его не будут испоьзовать авторы библиотек/фреймворков, то есть пока он не станет стандартом.
Сейчас оно выглядит на любительском уровне.

 

[Ragazzo]

Absinthe
обещают вроде как что Yii2 будет его использовать

 

[MiksIr]

MiksIr
некоторые утверждают что даже лучше, но это сомнительно. документация полное гавно, чтобы реально прицениться, я в закрытых тикетах копался, чтобы понять тупо как подгружать jquery.

Моя практика работы с системами зависимостей пакетов, развиваемыми кучей людей, показывает, что это очень быстро скатывается в неоправданное задирание версий, т.е. каждый новый пакет проставляет зависимости версий исходя из текущих свежих, а не реально необходимых. Как итог - неоправданное обновление. А учитывая общую температуру по больнице в PHP надеяться, что не мантейнеры не поломают обратную совместимость я бы не стал. Это если глобальная библиотека. А если на каждый проект своя... ну наверно у меня такие проекты, просто, когда внешних библиотек всего "несколько", воротить ради них такой вот "гем" считаю неоправданным. Уж лучше мухи отдельно, котлеты отдельно, в смысле, управление пакетами и DI. А для DI много разных решений. И gem-ы мне, как пользователю ruby софта, а не программисту, адски не нравятся. Идеология PHP "все свое ношу с собой" как-то больше импонирует для веб-продуктов.

 

[Absinthe]

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

Авторы большинства библиотек работают на добровольной неоплачиваемой основе, а задача "проверить ряд предыдущих версий для каждой зависимости" нудная и неинтересная.

 

[MiksIr]

Авторы большинства библиотек работают на добровольной неоплачиваемой основе, а задача "проверить ряд предыдущих версий для каждой зависимости" нудная и неинтересная.

Если берешься что-то делать - делай это хорошо. Если берешься что-то делать для других - делай это в 10 раз лучше. А "мне за это не платят" - всего-лишь отмазка людей, которые не могут работать хорошо. В 99% случаев они точно также работают за деньги. Профессионал не будет следовать принципу "бесплатно - значит можно лажу гнать", он или сделает хорошо, или не будет делать.

 

[Balancer]

Кстати, а нет ли готвого решения для работы с пакетами на уровне приложения? То есть, чтобы из работающего и настроенного приложения устанавливать/сносить пакеты, включая зависимости. Ну, скажем, в движке форума или CMS прямо из админки плагины ставить. Или в развёрнутом фреймворке из командной строки.

А то сейчас позарез уже назрело, но не хочется велосипедить, если такое уже где-то есть.

 

[Absinthe]

Если берешься что-то делать - делай это хорошо. Если берешься что-то делать для других - делай это в 10 раз лучше. А "мне за это не платят" - всего-лишь отмазка людей, которые не могут работать хорошо. В 99% случаев они точно также работают за деньги. Профессионал не будет следовать принципу "бесплатно - значит можно лажу гнать", он или сделает хорошо, или не будет делать.

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