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.

[ezimuel]

Sorry for the late reply. I'm working for a new release of elasticsearch-php for 9.x version and I would like to understand better the needs. Consider that when we'll release 9.x we will support only the last minor of 8.x. That means 7.x will not supported anymore.

[ezimuel]

@jgangso , @ruudk , @planchev I would like to propose a default client implementation (PSR-18) in elastic-transport-php that is the library that implements the HTTP transport layer. I started to work on it many years ago, see here. Maybe, I can resume this work and improve it so we can remove the guzzlehttp/guzzle dependency.
Using php-http/discovery makes sense from an engineering perspective, but I would still like to provide a default client so that users can use the library without needing to install an additional HTTP client

[ruudk]

but I would still like to provide a default client so that users can use the library without needing to install an additional HTTP client

I get that this is nice, but is it that important? I would really advise not to do this. You could change the readme so that it says something like this:

To install Elasticsearch, run composer require elasticsearch/elasticsearch guzzlehttp/guzzle

Now newcomers, who probably copy and paste this command anyway, immediately install guzzle too.

And for people that care more about this, they see guzzle, and don't install it. We could also add a comment next to it, saying that guzzle is optional, and any PSR-18 client can work. For example, when you're on Symfony, you might want to use symfony/http-client.

[ruudk]

Next to that, you could add a suggest to the composer.json file, that guzzle can be used as PSR-18 client.

[ezimuel]

I just released v9.0.0 of elastic-transport-php with the changes proposed in this issue. We will use this version for elasticsearch-php 9.0.0 coming soon.