vasa_c
Новичок
Здравствуйте, уважаемые Знатоки! Тема сегодняшнего вопроса: "Composer и как его победить?".
Решил я компенсировать своё отставание от жизни и изучить все модные штучки, которые появились в последнее время.
Вот, дошёл до компосера. Все его используют и если ты выложил на гитхаб php-проект, а в корне нет composer.json, то с тобой даже здороваться перестанут.
Три раза я пытался в нём разобраться и все три раза останавливался при спонтанном возникновении чувства острой личной неприязни.
У меня есть несколько объяснений этому:
1. Эта вещь не для моего гуманитарного ума. Но, например, node+npm+grunt, недавно освоил с нуля за пару дней. Там всё чётко, логично и ясно. Здесь ничего не понять и документация не сильно помогает.
2. Я просто не могу ухватить сакральную философию компосера.
3. Либо вариант - это действительно ещё весьма сырое поделие.
Причём, даже не сырое, а складывается впечатление, что его изначально делали под какую-то определённую жёсткую инфраструктуру.
А потом решили выкатить для всеобщего использования и наспех допилили.
Ещё похоже, что в нём пытались использовать соответствующие подходы из других технологий, особенно не задумываясь, как это подходит к PHP.
Собственно, пример.
У меня на гитхабе библиотека. В ней есть каталог с, собственно, библиотекой. Есть вспомогательные библы, юнит-тесты, билды какие-то, документация и др.
Я так и не смог заставить компосер ставить то, что нужно. Он сливает вообще всё барахло. Более того, он клонирует всё это в конечной папке, то есть там остаётся репа .git. Теперь все эти либы в общий гит не положишь нормально.
В npm похоже, но там можно указать нужные файлы. Он всё во временный каталог склонирует и потому скопирует только то, что нужно.
Итого, вопрос: так и задумано или у меня руки кривые?
Структура каталогов
Всё валится в vendor в совершенно непонятной последовательности, плюс там создаются от самого компосера свои суррогатные автолоадеры и другой треш.
Только что внедряли стандарт PSR-0, благодаря которому можно написать один загрузчик в одну строчку, а потом просто класть все либы в соответствующие подкаталоги. И теперь те же люди внедряют совершенно противоположный подход. Я в замешательстве!
Версии
К чему вся эта морока со указанием версий, "master-dev" и всем остальным? Вы видите в этом реальный смысл?
Вот nodejs+npm, там с этим всё понятно, логично и органично. Модули не имеют глобальных имён и все свои зависимости ставят себе локально.
То есть, в системе одновременно может существовать модуль A, которых хочет B версии 1.2 и модуль C, который хочет B v1.1. И эти две версии B будут существовать параллельно.
У PHP никак две версии одной библиотеки параллельно не поставишь.
Именование
Именования пакетов, все эти "вендор/шмендор". Зачем?
В PHP есть чёткое имя, которое характеризует библиотеку - пространство имён.
То есть, вендор Вася написал класс MyClass и назвал его "vasa/MyClass", а Петя тоже MyClass наваял и назвал его "peta/MyClass".
С точки зрения компосера конфликтов пакетов не будет, но всё равно эти два пакета в одну систему никак не встанут.
Альтернативы
Можете указать какие-либо более-менее популярные альтернативы?
Пускай, даже, что-нибудь простое, которое не пытается ставить любую структуру из любых источников.
То есть, например, каждый пакет должен быть оформлен соответствующим образом, соответствовать PSR-0 и лежать в определённом месте.
Буду благодарен, если укажете, где ошибки в моих рассуждениях.
Решил я компенсировать своё отставание от жизни и изучить все модные штучки, которые появились в последнее время.
Вот, дошёл до компосера. Все его используют и если ты выложил на гитхаб php-проект, а в корне нет composer.json, то с тобой даже здороваться перестанут.
Три раза я пытался в нём разобраться и все три раза останавливался при спонтанном возникновении чувства острой личной неприязни.
У меня есть несколько объяснений этому:
1. Эта вещь не для моего гуманитарного ума. Но, например, node+npm+grunt, недавно освоил с нуля за пару дней. Там всё чётко, логично и ясно. Здесь ничего не понять и документация не сильно помогает.
2. Я просто не могу ухватить сакральную философию компосера.
3. Либо вариант - это действительно ещё весьма сырое поделие.
Причём, даже не сырое, а складывается впечатление, что его изначально делали под какую-то определённую жёсткую инфраструктуру.
А потом решили выкатить для всеобщего использования и наспех допилили.
Ещё похоже, что в нём пытались использовать соответствующие подходы из других технологий, особенно не задумываясь, как это подходит к PHP.
Собственно, пример.
У меня на гитхабе библиотека. В ней есть каталог с, собственно, библиотекой. Есть вспомогательные библы, юнит-тесты, билды какие-то, документация и др.
Я так и не смог заставить компосер ставить то, что нужно. Он сливает вообще всё барахло. Более того, он клонирует всё это в конечной папке, то есть там остаётся репа .git. Теперь все эти либы в общий гит не положишь нормально.
В npm похоже, но там можно указать нужные файлы. Он всё во временный каталог склонирует и потому скопирует только то, что нужно.
Итого, вопрос: так и задумано или у меня руки кривые?
Структура каталогов
Всё валится в vendor в совершенно непонятной последовательности, плюс там создаются от самого компосера свои суррогатные автолоадеры и другой треш.
Только что внедряли стандарт PSR-0, благодаря которому можно написать один загрузчик в одну строчку, а потом просто класть все либы в соответствующие подкаталоги. И теперь те же люди внедряют совершенно противоположный подход. Я в замешательстве!
Версии
К чему вся эта морока со указанием версий, "master-dev" и всем остальным? Вы видите в этом реальный смысл?
Вот nodejs+npm, там с этим всё понятно, логично и органично. Модули не имеют глобальных имён и все свои зависимости ставят себе локально.
То есть, в системе одновременно может существовать модуль A, которых хочет B версии 1.2 и модуль C, который хочет B v1.1. И эти две версии B будут существовать параллельно.
У PHP никак две версии одной библиотеки параллельно не поставишь.
Именование
Именования пакетов, все эти "вендор/шмендор". Зачем?
В PHP есть чёткое имя, которое характеризует библиотеку - пространство имён.
То есть, вендор Вася написал класс MyClass и назвал его "vasa/MyClass", а Петя тоже MyClass наваял и назвал его "peta/MyClass".
С точки зрения компосера конфликтов пакетов не будет, но всё равно эти два пакета в одну систему никак не встанут.
Альтернативы
Можете указать какие-либо более-менее популярные альтернативы?
Пускай, даже, что-нибудь простое, которое не пытается ставить любую структуру из любых источников.
То есть, например, каждый пакет должен быть оформлен соответствующим образом, соответствовать PSR-0 и лежать в определённом месте.
Буду благодарен, если укажете, где ошибки в моих рассуждениях.