Provide alternatives to getConfig()

[Alexis Lefebvre]

Description
In #2516, getConfig() was deprecated, but no replacement was suggested.

Example

We use https://packagist.org/packages/eightpoints/guzzle-bundle to use Guzzle in a Symfony project, with this config:

# config/packages/eight_points_guzzle.yaml
eight_points_guzzle:
    clients:
        example_api:
            base_url: "https://api.example.com/"
            options:
                timeout: 30
                http_errors: true
                headers:
                    User-Agent: "EightPointsGuzzleBundle/v7"
                    Content-Type: 'application/json'
                    TokenID: '%example_api_key%'
            plugin: null

The method that use Guzzle can return null early if no key is provided for this client, so that we can enable or disable the calls to the external API by changing the value of %example_api_key% in our different environments.

# src/ExampleClient.php

class ExampleClient
{
    public function __construct(
        private readonly \GuzzleHttp\Client $client,
    ) {
    }

    private function call(): ?array
    {
        if (!$this->client->getConfig()['headers']['TokenID']) {
            return null;
        }
        
        // …

        // the call to Guzzle is done here
        return json_decode(
            $this->client->post($uri, $parameters)->getBody(),
            true, 512, JSON_THROW_ON_ERROR
        );
    }
}

If getConfig() is removed in Guzzle 8, we won't be able to access to the config and disable these calls.

We could pass %example_api_key% to do the same thing but I think that it would be nice to rely only on the $client that already contain this value.

Additional context

Idea: add getHeaders() or something like getHeader('TokenID'), etc. to allow to access to the values that are accessible through getConfig() today with Guzzle 7.

See also #2514

[Vaidas Lungis]

use Middleware and check if request headers has TokenId ?

[Alexis Lefebvre]

use Middleware and check if request headers has TokenId ?

Thanks, it looks interesting: https://docs.guzzlephp.org/en/stable/handlers-and-middleware.html#middleware

[Graham Campbell]

This is marked as deprecated, but probably I won't actually ever remove this. I just want to encourage people to not use it.

[Srdjan]

I'm also using this Symfony package, like mentioned in the issue's description, and now I'm not sure how to push middleware to the existing client, currently I'm doing it like this:

$oauth = new OAuth2Middleware();
$this->guzzleClient->getConfig('handler')->push($oauth);

With getConfig being deprecated is there an alternative to achieve the same functionality?

[nimafallahian]

I see you've mentioned you'll probably never remove this but the issue is I'm using phpstan to draw the attention to problematic lines of code in my codebase. I can ignore these lines but would prefer to have them out of deprecation notice or have an alternative to it. It would be wonderful if it's part of your plan to do one of these. :)

[Graham Campbell]

You can view this as technical debt in your code. We do not recommend using that function, but we appreciate many people do.

[Alexis Lefebvre]

I'm also using this Symfony package, like mentioned in the issue's description, and now I'm not sure how to push middleware to the existing client, currently I'm doing it like this:

$oauth = new OAuth2Middleware();
$this->guzzleClient->getConfig('handler')->push($oauth);

With getConfig being deprecated is there an alternative to achieve the same functionality?

Should it be asked and/or documented on the bundle repo? https://github.com/8p/EightPointsGuzzleBundle

[Graham Campbell]

You would need to create the handler then construct a guzzle client with said handler.

[Graham Campbell]

Much like in #3185.

[Liam Morland]

In Drupal, a Guzzle client can be injected. We need to know what its settings are so that we can create a client with our own settings based on that. I don't see a way around this. This is what we use getConfig() for.

[Leonardo Wiedemeier]

@GrahamCampbell

This is marked as deprecated, but probably I won't actually ever remove this. I just want to encourage people to not use it.

What speaks against marking this function as internal insetad of depcrecated?