Как решить проблему совместимости пакетов в PHP?

Question

[DYLAN]

Суть проблемы проста. Допустим у нас есть какая CMS'ка, которая построена на пакетах (Prestashop, Magento, OctoberCMS и т.д.). Мы написали некоторый модуль, и используем Guzzle версии 7. К нам приходить заказчик с магазином на Prestashop (https://github.com/PrestaShop/PrestaShop/blob/deve... у которого стоит guzzle 5 версии) и говорит, установи мне свой модуль. Мы устанавливаем его, и при выполнении получаем ошибку, т.к. autoload ядра отработает и подключит свой guzzle. Мы можем в composer.json своего модуля установить prepend-autoloader = true, но тогда это приведет к некорректной работе самой CMS.

Как решить данную проблему?

Comments

[Flying]

Как вариант: делать работу в своём модуле через дополнительную абстракцию и писать адаптеры для разных версий Guzzle, а дальше подстраиваться под то что есть в системе.

Либо же, если позволяет архитектура системы, иметь полностью свой vendor и работать с нужной вам версией, не показывая её наружу.

[DYLAN]

Flying, а можно подробней про эти пути?

Архитектура системы имеет свой vendor, но если до этого был подключен загрузчик от ядра, а потом мой в модуле и composer.json моего модуля написано prepend-autoloader = false, то будет запущен сначала загрузчик ядра CMS, который найдет у себя в vendore данный класс и подключит его.

[Flying]

DYLAN, В первом случае вы описываете некий интерфейс (или интерфейсы) которые будут выполнять нужные вам функции. Далее вы делаете две реализации этих интерфейсов, которые используют соответственно Guzzle 5 и Guzzle 7. После этого, обычно, удобно иметь ещё какой-то класс, реализующий паттерн Facade, который позволит упростить взаимодействие, а уже он в качестве зависимости должен получать тот или иной адаптер в зависимости от того какая из версий библиотеки имеется в наличии.

По поводу собственного autoloader'а: я подумал и скорее всего это будет создавать больше проблем чем решать, так что я бы склонялся к описанному выше варианту.

[DYLAN]

Flying, в общем принял решение слить текущую версию Guzzle себе в SDK. Guzzle имеет лицензию MIT, а значит можно спокойно присваивать их код себе. По сути это как если бы я написал собственный http client. Мне кажется это самый разумный способ, хотя первое время меня сильно корёжело от этой мысли, но немного подумав, понял, что варик вполне себе.

[Flying]

DYLAN, На самом деле если для важно наличие http client'а как такового, а не обязательно Guzzle - то проблемы вообще нет. Просто возьмите другой http client, свет клином на Guzzle не сошёлся.

Я, к примеру, в своих проектах предпочитаю использовать symfony/http-client