Open jgangso opened 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.
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.
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
thanrequire
, and will emphasise that there are obvious disadvantages of the latter.