-
Notifications
You must be signed in to change notification settings - Fork 963
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Requiring guzzlehttp/guzzle
causes roadblocks
#1370
Comments
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.The text was updated successfully, but these errors were encountered: