Не имеют зависимостей!
Да, серьезно. Если вы разработаете клиент API, который будет использовать Guzzle в качестве HTTP-клиента, вам нужно сделать выбор: использовать Guzzle версии 3, 4, 5 или 6?
Guzzle 3 не обслуживается и заброшен. Вы не захотите его использовать.
Guzzle 4 также считается окончанием срока службы, поскольку версия 5 была очень быстрой. Никто не использует эту версию.
Это сводится к использованию либо версии 5, либо 6. Но Guzzle использует одно и то же пространство имен и, вероятно, те же имена классов в обеих версиях, но несовместимы друг с другом. Независимо от того, какую версию вы выберете: ваш клиент сделает противоположный выбор - и теперь у вас есть кодовая база, в которой одновременно работают две версии Guzzle - это не сработает.
Если у вас нет зависимостей, но доставляйте все в пределах своей собственной кодовой базы, у вас есть весь ваш код под вашим контролем и уменьшает необходимость использования Composer в качестве инструмента для простой установки всех ваших зависимостей. В вашем пакете будет все, что уже включено, маловероятно, что будут конфликты пространства имен.
Вы можете предложить ZIP-файл для загрузки. И если вы дополнительно предложите composer.json, чтобы разработчики могли включить ваш пакет таким образом, все будут счастливы.
Update
Теперь, узнав, что все думают, что я сумасшедший предлагает не использовать материал, изобретенный в другом месте, я призываю вас еще раз подумать о ситуации: Вы обнаружите, что вы должны создать код, который будет вероятно, будет включен в кодовую базу, которая НЕ управляется с помощью Composer. Это означает, что вы не представляете, какое программное обеспечение там собрано.
Это может быть просто так, что у вас есть версия Guzzle в существующей кодовой базе - невозможно обнаружить, потому что нет composer.json. Теперь вы предоставляете свой собственный пакет в комплекте с версией Guzzle (независимо от того, как он появился там). Это может привести к сбою всего программного обеспечения в какой-то момент из-за конфликтов, поскольку автозагрузка, конечно же, будет объединена в какой-то момент, а затем часть кода запросит некоторый класс Guzzle для загрузки, который включен дважды из двух разных версий из Гуззала.
ЧТО ДОЛЖНО ПРОИЗОЙТИ В ЭТОМ СЛУЧАЕ? ВЕЩИ БУДУТ СКАЗАТЬ!
И это неизбежно, что это произойдет. Даже в счастливом случае использования Composer это будет конфликтовать - программное обеспечение не будет разбиваться, но весь пакет не будет установлен. Хорошо: вы сразу заметите это.
Если основная задача состоит в том, чтобы доставить клиент API, который любой может использовать в любой ситуации, без использования менеджера зависимостей: Не имеют зависимостей!
В качестве альтернативы, убедитесь, что знаете, какое программное обеспечение уже используется, и создайте пакет, который в любом случае не будет конфликтовать. Тем не менее, это все еще усилие, потому что могут быть установлены другие дополнения, которые могут включать конфликтующее программное обеспечение.
Мой центральный пункт: Если у вас нет менеджера зависимостей, например, Composer, который может управлять зависимостями, вам лучше не иметь зависимостей в своем собственном коде, чтобы сделать его очень простым для включения собственного кода в кто-то другой код базы.
И в приведенном выше вопросе четко указано, что композитор не является вариантом в общем случае.
Теперь в конце туннеля есть один свет: когда дело доходит до общих задач, PHP-FIG начал стандартизировать интерфейсы, которые должны использовать интероперабельность. Для HTTP стандарт - PSR-7.
Вы МОЖЕТЕ предоставить API-интерфейс API, который зависит (и приносит с собой) интерфейс PSR-7 и требует, чтобы пользователь SDK предоставлял HTTP-клиент, который реализует этот интерфейс.
Проблема с этим подходом, я вижу, что вы все равно столкнетесь с неприятностями, если попытаетесь использовать, например, Guzzle по той же причине: единственный правильный выбор сейчас - использовать Guzzle 6 для SDK - что, если Guzzle 5 был уже использован в другом месте? Конфликт! Хорошая вещь: вы можете избежать использования Guzzle 6, если вы уже используете Guzzle 5, используя любой другой HTTP-клиент с поддержкой PSR-7.
Вместо того, чтобы отвечать только на то, чтобы указать на модель AWS, почему бы вам не написать самостоятельный ответ после того, как вы сформулировали стратегию для своего собственного проекта. –