Add support for the incoming `league/oauth1-client`

[bencorlett]

Hi team,

I'm working on a v2 for league/oauth1-client. We have decoupled completely from Guzzle. In fact, we require:

1. PSR-7 message implementation - list.
2. PSR-17 HTTP message factory implementation - list.
3. PSR-18 HTTP client implementation - list.

For PSR-7, we suggest the incorporation of guzzle/psr7, which is a dependency of both Guzzle 6 and Guzzle 7.

For PSR-17, we suggest the incorporation of http-interop/http-factory-guzzle, which creates guzzle/psr7 message objects.

For PSR-18, we suggest either:

1. guzzlehttp/guzzle 7+, which only supports PHP 7.2+.
2. php-http/guzzle6-adapter, which adds support for Guzzle 6, which is perfect for PHP 7.1.

Of course, the end user can decide the implementation they prefer. We have no direct coupling to any.

The issue comes to a turnkey solution like Socialite. I'm trying to think of how to put together a PR for socialite to add support. This is very trivial within PHP 7.2+, but with PHP 7.1, it gets a little trickier due to your explicit requirement of Guzzle 6 or Guzzle 7.

If, for PHP 7.1, I add a specific requirement for php-http/guzzle6-adapter to Socialite, this limits Guzzle to only ever being Guzzle 6, which obviously isn't a viable solution as I imagine most folks (at least on PHP 7.2+) have upgraded to Guzzle 7.

There are effectively three routes in order to get the much better v2 OAuth 1 Client:

1. To keep PHP 7.1 support, I also submit a PR to the documentation that states in PHP 7.1, you'll need to composer require php-http/guzzle6-adapter before pulling in Socialite.
2. Drop support for PHP 7.1.
3. I create a package similar to php-http/guzzle6-adapter that contains a factory which returns a decorator for Guzzle 6 (to add PSR-18 support) or returns Guzzle 7 (which has built-in PSR-18 support).

I'm not a huge fan of option 1. For me I think option 3 is the best solution.

What are your thoughts?

[bencorlett]

Thinking outside the box, I wonder if we can add a provides: psr/http-client-implementation to Socialite's composer.json file and then just delegate the PSR-18 responsibility to Guzzle, or decorate it ourselves…

[bencorlett]

Thinking outside the box, I wonder if we can add a provides: psr/http-client-implementation to Socialite's composer.json file and then just delegate the PSR-18 responsibility to Guzzle, or decorate it ourselves…

Yes, this does work. However, this would add a bit of additional code, at least 3-4 classes. You'll notice how php-http/guzzle6-adaptor wraps not only the client but also the PSR-18 exceptions.

Anyway, let me know your thoughts and preferences and I'll invest more effort exploring the preferred solution at that point.

[bencorlett]

It looks like there's a discussion over here on precisely this issue.

[driesvints]

@bencorlett We're about to release Socialite 5 with Laravel 8 support on Tuesday which drops PHP 7.1 support: https://github.com/laravel/socialite/blob/master/composer.json#L18

We can bump league/oauth1-client to v2 for that but it would need to be done before Tuesday. I'm not available on Monday but I can review anything on Tuesday itself before tagging the major release. Do you think it's possible before that?

Otherwise the next window will be in February for Laravel 9.

[driesvints]

Hey @bencorlett. Were you still working on v2?

[driesvints]

Gonna close this one until there's info on when work on v2 is picked up again.