Что на счёт composer?

[kernusr]

Поскольку либа, в перспективе, планируется к использованию, паралельно, в нескольких решениях разных авторов - может обернём её для composer? Так удобнее будет следить за актуальностью полей, в своём ешении.
Ставить отдельной библиотекой нет смысла, т.к.:
1 - это всёже отдельная библиотека, а значит кто-то может её обновить раньше, чем остальные "подтянут" свои решения
2 - поставив из composer'а, можно выкинуть не используемые поля
3 - не обязательно следить за совместимостью с версиями. Каждый автор локально обновляет свои зависимости
4 - увелисить долю чего-либо о Joomla! в на https://packagist.org/

Из недостатков:
1 - одно и то же поле будет жить на сайте в нескольких экземплярах, но без конфликта

[kernusr]

• хороший опыт для нас всех по публикации в https://packagist.org/
  Кто-нибудь там публиковался уже?

[dmitriitux]

@kernusr в джумле же не работает нормально композер

[dmitriitux]

@kernusr я планирую написать систему зависимостей расширений

[dmitriitux]

ну подцепить то можно, просто вроде же не работает адекватно, и поставлять в расширения как-то надо, а как?

[dmitriitux]

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

[kernusr]

я не говорю, об установке в джумлу прямо из композёра
Я, например, использую его для установки дополнительных библиотек в конкретный проект.
Да, я нарушаю парадигму размещения библиотек в джумла, размещая библиотеку, внутри своего решения, в папке, которой мне удобно. Но я сам контролирую е версии и я уврен, что никто не обновит мою зависимость, установив другое расширений
С другой стороны - когда я использую одну и ту же библиотеку в нескольких расширениях - мне достаточно написать composer update и получить актуальную версию библиотеки, не пугаясь, что это могло сломать совместимость с другим моим расширением

Самый яркий пример - библиотеи, которые в required php version ставят 7,3. Но если такую библиотку ставить в решение "на массу", то нужно учитывать работу с php 7.1, как минимум

[kernusr]

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

К стати - эо тоже немаловажный фактор
И, скорее всего, для создания полноценной системы зависимостей придётся написать очень много "обвесов" для инсталлера и постоянно проверять уйму параметров

[dmitriitux]

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

[dmitriitux]

то есть ты имеешь ввиду ставить как копию по сути, чтобы композер подсасывал?

[dmitriitux]

@kernusr насчет что затрет, то можно поставлять либу только по ссылке в пакете, чтобы не шел устаревший архив, а только выкачивался

[kernusr]

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

Но добиться качественного бесконфликтного использования не удастся, пока не будет внедрения на уровне ядра. А там его, как мы можем судить по "дедам", не будет

Да и com_installer Разве хорошо так обвешен триггерами, чтоб вмешаться в любое действие с установкой?

[dmitriitux]

это по сути маркетплейс будет и альтернатива jed

[kernusr]

со своими правилами составления манифестов?

[dmitriitux]

и почему не удастся? по сути идет выкачивание и обновление через стандартный com_installer

[dmitriitux]

это надстройка по сути и не более