Relax the Guzzle client requirements
danwkennedy opened this issue · 6 comments
I'm not sure why guzzle needs ">=4,<6". It's problematic though since our apps use 6+.
Looking at the forks, it looks like this is being tested here https://github.com/cberube/consul-php-sdk/commit/2c0b1ee29bd5e7fed82d35d8ca2d445df0ac6ee8 is there an update available on Guzzle 6 support?
It's a bit boring that guzzle is not BC. I don't really know how to handle that.
May be @stof has an idea.
Guzzle 6 is a complete rewrite of Guzzle.
For the previous complete rewrite, they made the right choice by making it a different library in a different namespace, allowing to have Guzzle 3 and 4 in parallel.
Guzzle 6 does not unfortunately, and there is no way to write code working with both 5 and 6 (it is possible for 4 and 5 because the BC breaks only happen in some places). The only way would be to abstract all usages of Guzzle behind your own interfaces, and have 2 implementations (Guzzle 4/5 and Guzzle 6). And given that Consul makes guzzle options a part of the public API of the SensioLabs\Consul\Client class, it is impossible to abstract away from guzzle without a BC break in the library (Guzzle 6 options are not the same).
And given guzzle is used by so many projects, it is a pain (too bad they don't consider backward compatibility as a feature, as it actually makes the library unsuited for such large usage)
What you could do to make the Consul SDK decoupled from guzzle is to depend on https://github.com/php-http which provides a PSR-7 based HTTP client interface, and provides implementations based on several existing HTTP clients (currently, only Guzzle 5 and Guzzle 6 adapters are implemented). this would allow people to use either guzzle 5 or 6 depending on their needs. The drawback would be that they would always have to require one of the adapters themselves (if you require the guzzle 6 adapter all the time to be sure to get one adapter without extra work, it would prevent to install the guzzle 5 one because of conflicts in the guzzle requirements)
Another suggestion is to use Buzz. The project is not very active, but it is stable.
On a side note, this is one of the reason why I like Symfony so much (and why it is good for Drupal or ezPublish to use it): we care a lot about backward compatibility (even for upgrades between major versions)
As Guzzle is only used as a very basic HTTP interface, I would not bother too much and I would use plain old PHP code. @lyrixx Let's talk about that tomorrow :)
I'm glad I looked here!
I'm in a similar boat. I have another package I'd like to install which uses Guzzle 6 and, since Consul is the only other use of Guzzle I have, I forked and made some modifications to upgrade to Guzzle 6. I was going to ask if you wanted me to give you a PR for these modifications, but it looks like you have some wider views as to how this upgrade might affect your project.
If you'd like to see them, then you can take a peek here: https://github.com/XerxesDGreat/consul-php-sdk
I'm closing as guzzle is not used anymore