elastic / elasticsearch-php

Official PHP client for Elasticsearch.
https://www.elastic.co/guide/en/elasticsearch/client/php-api/current/index.html
MIT License
5.25k stars 963 forks source link

Requiring `guzzlehttp/guzzle` causes roadblocks #1370

Open jgangso opened 9 months ago

jgangso commented 9 months ago

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 commented 9 months ago

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 commented 8 months ago

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.