Leverage php-http/discovery to let users choose their HttpClient implementation

[welcoMattic]

As it's done in OpenAI PHP Client, it could improve the interoperability to leverage https://github.com/php-http/discovery (and psr/http-client-implementation + psr/http-factory-implementation) to reuse HttpClient installed in users' projects or suggest them one that implements PSR-18 interface.

OpenAI PHP Client choose to not be hard dependent on any other Http Client implementation to let use an already installed Http Client or suggest one, comptible with PSR-18.
I'm opening this issue to replicate this behavior to php-llm/llm-chain, instead of "forcing" users to use symfony/http-client.

I'm writing this issue just after attending to Nicolas Grekas talk about how SDK maintainers could help to improve Http Clients interoperability.

I'm looking to open a PR as soon as possible.
First step first is to identify where live hardcoded dependencies to Symfony HttpClient.

Let me know if this suggestion is something you will be ok to accept 🙏

Thanks!

PS: I've opened the same issue on

• feat(http-interop): Switch hard references to Guzzle with php-http/discovery abstraction LLPhant/LLPhant#341 🙈

[chr-hertel]

Thanks for raising that - and I'm aware of that best practice, true.
I'm def biased here since I have a tendency to always use Symfony's HttpClient, favor that contract over the PSR and currently don't see the harm - I'd agree that in combination with the framework we should potentially revisit the DIC integration, and totally get the interop argument.

Did you have a concrete pain point in mind you could spot?

That would help understanding the priority, other than that I would rather not invest here atm - at least not before I got #316 done - would be too many open ends. And maybe this stunt here would be easier after that.

So, I'm def not totally against that, let's keep it open, and revisit later 🙏