Конфликт Prestashop Guzzle
Я обновляю модуль prestashop, добавляя пакет, который использует жрать6.0.
Prestashop 1.7 использует старую версию Guzzle 5.
Когда я устанавливаю плагин в Prestashop, версия Guzzle из включенного пакета конфликтует с версией Prestashop, что приводит к следующей ошибке php.
Uncaught PHP Exception InvalidArgumentException: "Magic request methods require a URI and optional options array" at /var/www/html/modules/package/vendorpackage/guzzlehttp/guzzle/src/Client.php line 81 {"exception":"[object] (InvalidArgumentException(code: 0):Magic request methods require a URI and optional options array at /var/www/html/modules/package/vendorpackage/guzzlehttp/guzzle/src/Client.php:81)"} []
Я нашел еще несколько примеров подобных проблем:
- Классы модуля PrestaShop не найдены (пространства имен)
- http://forge.prestashop.com/browse/BOOM-2427
- Prestashop 1.6, конфликт: 2 разных модуля, требующих одного класса, разных версий
- https://github.com/Nexmo/nexmo-php/issues/77
На основании этого у меня есть несколько идей, как обойти проблему. Ни один из этих способов не кажется правильным. Конечно, есть более чистый способ справиться с подобными проблемами с помощью композитор?
Извлеките Guzzle из прилагаемого пакета - это самый простой, моя проблема в том, что если я удалю эту зависимость, где она остановится, что сказать, какие-либо другие зависимости не будут конфликтовать позже по строке, которую нельзя удалить?
Может проверять версию Guzzle в пакете и менять вызовы в зависимости от того, какой из них загружает - аналогично описанной выше проблеме я могу взломать исправление, чтобы определить, какой тип вызова я должен использовать для этой ошибки, но я не могу сказать, какие еще проблемы это может вызвать, и мой код может в конечном итоге завален операторами для каждой версии.
Вручную изменить пространства имен guzzle в плагине. Таким образом, я могу зайти в папку поставщика моего пакета и указать конкретное пространство имен для пакета, я предполагаю, что это решит мою проблему, но я теряю смысл установки повторно используемого пакета.
Разверните Guzzle и обратитесь к этой версии. Я мог бы форк guzzle и включить его как пакет VCS в плагин. Проблема здесь в том, что я должен поддерживать это в дальнейшем.
Я не думаю, что здесь есть хороший способ - главный вопрос должен заключаться в том, почему кто-то выпустил модуль для Prestashop, который явно несовместим с PS. Можно ли запросить более старую версию этого зависимого модуля?
Ответы 5
В вопросе не уточняется, какова основная цель. Если ваша основная цель - обновить Prestashop (а не устранить конкретную ошибку), я предлагаю вам создать локальную установку среды Prestashop - и использовать ее для обновления производственной среды вручную, файл за файлом. Это можно сделать следующим образом:
Создайте новую установку Prestashop в предполагаемой версии (1.7.5?) На вашем локальном компьютере (используйте новую базу данных). Composer гарантирует, что две установки используют одни и те же зависимости.
Сделайте резервную копию производственной базы данных и восстановите ее на локальном сервере базы данных.
Перенастройте локальный Prestashop для связи с локальной базой данных.
Обновите местный Prestashop. Убедитесь, что эта обновленная установка работает.
Сравните локальную установку с удаленной с помощью инструмента сравнения (например, Вне всякого сравнения). Любые различия между двумя установками необходимо рассматривать в индивидуальном порядке:
- Скопируйте новый / обновленный код из локальной установки в удаленную.
- Удалите все устаревшие файлы из удаленной установки.
Обновите производственную базу данных.
Не забудьте сделать резервную копию программного обеспечения и базы данных перед тем, как начать.
Основная цель - иметь возможность включить версию guzzle в дополнительный плагин, не конфликтуя с собственной версией Prestashop. Хотя это отличный пример того, как исправить отдельный сайт Prestashop, он не решает то, что я ищу.
Способ самый легкий - выбрать альтернативный пакет для жрать, но он может быть не лучшим для вас.
- Плюсы
Вы экономите много времени
- Минусы
Вы используете другой пакет, чтобы делать то же самое.
Способ умеренный - это форк guzzle, а затем вы вручную изменяете пространства имен.
- Плюсы
Вы ничего не меняете в Prestashop.
Если Prestashop обновится до guzzle 6.0, вы легко сможете на него переключиться.
- Минусы
Вы должны поддерживать свою собственную индивидуальную жизнь.
Способ тяжелейший - самостоятельно пропатчить Prestashop
- Плюсы
Вы получаете все, что хотите.
Отправьте запрос на перенос, вы можете помочь многим другим.
- Минусы
Если Prestashop продолжит использовать guzzlehttp 5.0, вы попадете в кошмар исправлений.
Выводы
Я бы выбрал умеренный путь, если бы я жрал должен. Если бы я просто хотел сделать что-то особенное в нескольких строках кода, я бы просто использовал альтернативный пакет. И НЕТ вы не можете установить разные версии одного и того же пакета композитором.
Короткий ответ: тут ничего не поделаешь.
Длинный ответ: я как бы нашел способ решения вашей проблемы, учитывая, что я в той же ситуации.
Если ваш модуль зависит от пакета, который зависит от Guzzle, и если этот пакет находится под вашим контролем, вы можете использовать в своем пакете HTTPlug. Это абстракция, и она полагается на кого-то другого, включая фактическую клиентскую библиотеку HTTP. Этим кем-то также может быть вы, включая другую реализацию PHP-http / клиент-реализация.
Со временем, поскольку Prestashop может также использовать этот подход (наряду с другими платформами), все они могут в конечном итоге полагаться на PSR-7 абстракции HTTP-сообщений.
На самом деле это не решение вашей текущей проблемы, а, скорее, стратегия на долгосрочную перспективу, которая также может помочь вам понять, где вы находитесь сейчас.
Можете ли вы объяснить, как это должно работать, если для другого модуля требуется Guzzle v6?
Я не понимаю, как у другого модуля не будет такой же проблемы, как у вашего собственного. Поэтому я считаю, что нужно включить абстракции PSR7 и позволить Prestashop включить в свое ядро реального клиента (Guzzle).
Что ж, проблема есть и остается: PS поставляется с требованием Guzzle v5, модуль, который должен быть установлен с требованием v6. Обновление Guzzle до более новой версии Само PS отмечено в заявке с октября 2018 года, но очевидного прогресса нет - поэтому я не думаю, что здесь применимы какие-либо идеи использования PSR7.
Вы спросили, что произойдет, если другой модуль (не тот, который вы разрабатываете) потребует Guzzle v6. Я сказал, что не может. Я также сказал, что абстракции PSR-7 - это нет, решение текущей проблемы, но, скорее, долгосрочный способ для всех разработчиков модулей. Что мы обсуждаем?
Мы должны обсудить, как помочь ОП с его проблемой. Заявление о том, что программное обеспечение, которое он использует (Prestashop), требует доработки, не входит в обязанности ОП, но, как вы сказали, что нашли обходной путь, вам, вероятно, следует пойти дальше, объяснив, что
Вы можете просто использовать "guzzlehttp/guzzle": "~5.0", в файле composer.json вашего модуля и той же версии, которая использует prestashop.
Нет: если OP использует другой модуль, зависящий от Guzzle v6, нет возможности потребовать другую версию в собственном модуле.
У вас есть два решения:
- Найдите версию вашего пакета, в которой используется GuzzleHttp 5 (если доступно).
- Найдите альтернативу вашему пакету.
И НЕ РЕКОМЕНДУЕМЫЕ решения:
- Чтобы изменить пространство имен Guzzle в вашем пакете и установить guzzle 6 тоже.
(например:
use GuzzleHttp\=>'use GuzzleHttpSix\')
Это происходит из-за конфликта в используемом пространстве имен (ведьма одинакова для guzzle 5 и 6). И Prestashop отдает приоритет своим пакетам.
Довольно хакерский, но если вы действительно хотите пойти по этому пути, вы можете зарегистрировать собственный автозагрузчик, который скопирует вашу версию файлов пакета Guzzle во временные файлы с пространством имен в файле, замененным на все, что вы хотите, а затем вместо этого включит временные файлы.