Что на счёт 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]

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

[dmitriitux]

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

ну заходишь в маркет плейс и указываешь зависимости

[kernusr]

как ты планируешь зависимости отслеживать?

[dmitriitux]

как ты планируешь зависимости отслеживать?

на каком уровне имеешь ввиду? ну проверки :)

[kernusr]

На сколько я понимаю - в манифесте должны быть перечисленны все пакеты, с которыми ты взаимодействуешь. И их версии!
Как package.json в npm, например

[dmitriitux]

ну да, будет только в веб браузере в маркет плейсе, в центре

[dmitriitux]

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

[kernusr]

А как это сделать, не заставив разработчиков следовать твоим правилам составления манифестов, к своим расширениям?
И если делать отдельно, удалённую базу, то кто будет актуализировать версии зависимостей?
Я вот этот момент вообще не пойму

[dmitriitux]

допустим, есть плагин, которому нужна lib_fields, есть квантум который нужен lib_fields.
Что мы делаем, мы создаем два пресета внутри маркетплейса и вносим расширения которые идут там и зависимости какие нужны

[kernusr]

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

Поясни! Я не понял. Кто собирать будет? Разработчик или ты на сайте ставить будешь виртпакет?

[dmitriitux]

А как это сделать, не заставив разработчиков следовать твоим правилам составления манифестов, к своим расширениям?
И если делать отдельно, удалённую базу, то кто будет актуализировать версии зависимостей?
Я вот этот момент вообще не пойму

с поддержкой других, кто захочет сам будет, где мне интересно я буду

[kernusr]

а, я тебя понял. Ты хочешь, как в линуксе, ставить метапакеты

[AlekVolsk]

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

посмотри на master3, либа юикита тянется не в составе пакета, а в скрипте инсталла

[dmitriitux]

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

посмотри на master3, либа юикита тянется не в составе пакета, а в скрипте инсталла

ммм, кстати да, пока идея вынести вне пакета если используется где-то еще

[dmitriitux]

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

[dmitriitux]

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

[kernusr]

Интересно, а из почты опубликуется ответ... Я предложил композер на случай, чтобы не тягать либу за собой. Чтобы собирать не модульные, а монолитный решения. Но, если ты собрался делать менеджер зависимостей, то можно использовать его и не париться с композером вс, 8 мар. 2020 г., 0:01 Dmitrii <[email protected]>:

…

@kernusr <https://github.com/kernusr> насчет композера я так и не понял зачем он нужен, можешь еще раз сказать по проще зачем он нужен, просто есть обновление либы в рамках джумлы — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD2HLDRD4O77PEM2MF3LM53RGKYZ3ANCNFSM4LDD32PA> .

[dmitriitux]

@kernusr https://github.com/Quantum-Manager/pkg_quantummanager/blob/master/script.php#L214
вот скрипт установки, ставится от пакета отдельно, то есть когда удаляется пакет, не удалится либа. И когда поставится другое расширение, которое использует либу, то она просто его принудительно обновит