Add Guzzle7 Adapter Client Discovery

[barryvdh]

Related:

Q	A
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	no
Related tickets	fixes php-http/guzzle6-adapter#72
Documentation	Adds support for https://github.com/php-http/guzzle7-adapter
License	MIT

What's in this PR?

Adds support for https://github.com/php-http/guzzle7-adapter

Why?

To provide the HttpClient for Guzzle7

Checklist

• Updated CHANGELOG.md to describe BC breaks / deprecations | new feature | bugfix

[dbu]

thanks!

can you please also add an integration test for the adapter so we can ensure it keeps working, very similar to

discovery/.travis.yml

Line 67 in 87b580c

- install_test will-find "Http\Discovery\HttpClientDiscovery::find();" "php-http/guzzle6-adapter:^2.0.1"

[dbu]

oh, and no need to worry about the phpspec 8 failure in the test suite - that is unrelated to what you are doing.

[barryvdh]

Seems to be passing :) (Used 0.1 though, because there is no 1.x yet)

[dbu]

looks good, thanks!

@Nyholm fine like this or do you notice any issues?

[Nyholm]

Yes, it looks good.

Thank you

[dbu]

tagged as 1.12.0 https://github.com/php-http/discovery/releases/tag/1.12.0

[GrahamCampbell]

I would actually be 👎 against the creation of that Guzzle 7 adapter. People should be using the PSR interfaces these days, which Guzzle 7 already provides. No need to create a Guzzle 8 adapter, certainly, when Guzzle 8 is released.

[sagikazarmark]

@GrahamCampbell The Guzzle 7 adapter implements the async version of HTTPlug, so for those in need of HTTPlug async, this is necessary.

For those who already use PSR-18 only, Guzzle 7 will be discovered directly.

[dbu]

another valid use case is using guzzle 7 with older libraries that asks for httplug instead of psr-18.

but i agree that new projects that do synchronous requests should use psr-18 and not httplug these days.

[GrahamCampbell]

another valid use case is using guzzle 7 with older libraries that asks for httplug instead of psr-18.

I was rather hoping by not providing compat for that we'd encourage them to upgrade. Many maintainers aren't even aware that they could/should do that.

[dbu]

until there is a psr for async requests (which can't happen before there is a psr for promises), httplug can't be faded out anyways, so i think the cost of not forcing people to adapt is not that high. compared to the cost of people being confused why they can't find a http client when they have guzzle and the adapter installed. if they ask for a psr-18 adapter, they will get guzzle directly and not our adapter, so that is fine.