Requiring guzzlehttp/guzzle causes roadblocks

[jgangso]

I want to once again bring up the issue already discussed in #1337 about guzzlehttp/guzzle.

While I understood the reasoning for requiring guzzle was more about making life easier for the developers, it actually will potentially become a roadblock for some.

For instance, we have a Concrete CMS based project where even the newest version (9.1.3) requires guzzle ^6.3.
Elasticsearch 7.x is EOL anytime soon and we should upgrade to ES8. However, the ES client package versions 8.x require guzzle ^7.0 which conflicts with the requirement from Concrete CMS.

This leaves us in a poor position where we either have to run a EOL service or make own workarounds which sort of counter-works everything Composer stands for.

I agree with @ruudk that guzzle rather belongs to suggests than require, and will emphasise that there are obvious disadvantages of the latter.

[ruudk]

Maybe a solution could be to depend on https://github.com/php-http/discovery instead. This will still give a good developer experience, as it auto discovers a proper PSR client.

I said it before, but people that use Elasticsearch and this package, also know how to require a PSR HTTP client.

[planchev]

Guys, please, reconsider requiring guzzle as a dependency. We too have a huge legacy project, and we simply can't use latest version of elastic php client because our own code is standing on guzzle 6, and we can't easily upgrade that.