GuzzleHttp conflicts

[HHFabian]

Hey Klaviyo Team,
we use Shopware and use this SDK for a plugin. The problem we now have is that Shopware in our version still uses GuzzleHttp in version 5.3.3 and the SDK itself ^7.3. This leads to conflicts on our side and triggers errors. Is it possible to adjust the GuzzleHttp namespace to GuzzleHttp7 or GuzzleHttp73 in the SDK itself to prevent conflicts? A lot bigger non-Shopware codebases also use maybe old versions of guzzle, so this would enhance compability over various clients.

Best regards,
Fabian

[jon-batscha]

Hey Fabian,
Really appreciate you bringing this to our attention. We are taking a look at this now and exploring potential fixes. To make sure our solution properly solves your problem, can you confirm for me which of the following cases is currently happening on your system:

1. Our SDK is functioning correctly, but Shopware is not
2. Shopware is functioning correctly, but our SDK is not
   3 Neither Shopware nor our SDK are functioning correctly

Thanks!

[isfett]

Hey @jon-batscha, @HHFabian is actually on vacation so i will give the answers for him:
4. Shopware is functioning correctly, your SDK is either. When running isolated Unit-Tests all work pretty well. But if we want to use this in our Shopware Code, Shopware loads the 5.3.3 Guzzle and not your 7.3 Guzzle. For this we wanted to have a different namespace for this.

[jon-batscha]

Did some more research into this, and it looks like you can solve it relatively simply, as follows: Create a separate, blank folder for the Klaviyo installation, in which you will run composer require PACKAGE/NAME. By having its own folder, you will not run into version collisions as before.

Now, wherever you wish to use the Klaviyo SDK, you can import it as follows:

require_once('/PATH/TO/KLAVIYO/FOLDER/vendor/autoload.php');

Now your script will have access to the Klaviyo SDK, but it will be installed in such a way that it can have its required version of guzzle without impacting your shopware installation.

[isfett]

Hey @jon-batscha, this does not work for us.

We do have this library in an extra folder (plugins/klaviyo), with a own composer.json file and its required there. Also there is a vendor folder in this folder, where guzzle 7.3 is included and also klaviyo-php-sdk.

We then have a custom composer loader which:
a) Loads the shopware composer
b) Loads the klaviyo plugin composer with klaviyo-php-sdk required into the shopware loader and add the psr4 namespace of the plugin.

We then use the shopware internal dependency injection system (which is based on the symfony dependency injection container) to bootstrap the required classes (this uses composer as well). We then want to inject the https://github.com/klaviyo/klaviyo-php-sdk/blob/main/lib/Client.php into the class, which is working really well. But your Client just use "GuzzleHttp\Client" which causes the composer autoloading to get the guzzle 5.3.3 client located at vendor/guzzlehttp/guzzle instead of using plugins/klaviyo/vendor/guzzlehttp/guzzle. In this old version, there is no PSR7 interface etc, which causes Problems when sending requests to your API.

We also checked what happens if we just try to find out which class composer wants to load with $loader->findFile(\GuzzleHttp\Client::class); (also this shows the normal vendor directory)

As said before; everything works well in Unit-Tests where Guzzle7.3 is normally loaded without 5.3.3. But it does not work when using it in the real bootstrapped Shopware Application.

You could search the web and see that there are often Problems with having different Guzzle versions in a project and problems with autoloading like:
https://stackoverflow.com/questions/35679166/composer-using-two-different-versions-of-guzzle
and:
https://stackoverflow.com/questions/27150695/how-does-composer-handle-multiple-versions-of-the-same-package (Here you could see what our intentioon to this issue was: changing the PSR4 Namespace to GuzzleHttp73. This just works over the composer.json if the code is suited for this as well. Badly, all your classes in the API directory are autogenerated, without the possibility to regenerate them. So if we would fork this repository we could not get any updates.)

I hope our problem now is a bit more clear and you can help us out with changing the namespace or having any other ideas :)

[jon-batscha]

Appreciate you taking the time to reply in detail. As I understand, there are 3 possible solutions:

1. Option 1 is to update the version of shopware you are running so that it's compatible with our SDK. From what I can gather, the latest releases of shopware's shopware, core, and platform packages are compatible with the dependencies we use, at least as far as guzzlehttp's guzzle and psr7 packages are concerned.

2. Option 2 is to update Klaviyo/SDK to be compatible by doing a static vendor import for guzzle and psr7. Unfortunately, this is currently out of scope for our team, at least in the near term. Looking at some peer SDKs (shopify, facebook, etc), I see that they import guzzle and psr7 similarly, and deviating from that standard practice presents a complicating factor for us.

3. Option 3: Import Klaviyo without the custom composer class

Apologies I couldn't more helpful here. I'll keep an eye on this issue, and if anything changes, I'll be sure to follow-up with any new learnings.