How to configure the http client within Symfony

[Toflar]

Hey Dariusz!

I'm trying to configure Instructor to use a given Symfony HttpClient and EventDispatcher that are already registered in the DI container. So basically I have this:

use Cognesy\Http\Drivers\SymfonyDriver;
use Cognesy\Polyglot\LLM\Data\LLMConfig;
use Cognesy\Polyglot\LLM\LLM;
use Psr\EventDispatcher\EventDispatcherInterface;
use Symfony\Contracts\HttpClient\HttpClientInterface;

class MyFactory
{
    public function __construct(private HttpClientInterface $httpClient, private EventDispatcherInterface $eventDispatcher) {}

    public function createLLM(array $config): LLM
    {
        $llmConfig = new LLMConfig(
            apiUrl: 'https://api.openai.com/v1',
            apiKey: $config['api_key'],
        );

        $httpClientConfig = new HttpClientConfig('no-clue-what-this-is-yet');

        $client = new HttpClient();
        $client = $client->withDriver(new SymfonyDriver($httpClientConfig, $this->httpClient, $this->eventDispatcher));

        return new LLM('no-clue-what-this-is-yet', $llmConfig, $client);
    }
}

Integrating it in the default Symfony world would of course allow me to register events just like I normally would in the application and you would get the benefit of all the debug helpers when using the container registered HTTP client.
However, there are some questions here:

• SymfonyDriver expects a CanHandleHttpRequest? How is this supposed to work? Symfony's HttpClient will never implement that?
• The EventDispatcher argument expects Cognesy\Utils\Events\EventDispatcher, shouldn't it expect the PSR EventDispatcherInterface so it's compatible with all event listener libraries?

Thanks!

[ddebowczyk]

Let me think and come back to you.

[ddebowczyk]

Regarding: "The EventDispatcher argument expects Cognesy\Utils\Events\EventDispatcher, shouldn't it expect the PSR EventDispatcherInterface so it's compatible with all event listener libraries?"

Yes, probably it's the best way to make it future-proof. I aim to introduce this change in the v1.0.

[ddebowczyk]

Re: "SymfonyDriver expects a CanHandleHttpRequest? How is this supposed to work? Symfony's HttpClient will never implement that?"

This looks like my mistake :(
I've only tested Guzzle and Laravel and rushed while adding Symfony client. I'm sorry for the confusion this must have caused.

Let me correct this in v1.0.

[Toflar]

Thanks for the reply! Looking forward to the changes! Basically, in my case, I don't want to load any config from any files but instead control the creation of the LLM and the http client and event dispatcher it is using completely myself 😊

[ddebowczyk]

Can you show an example of your ideal code? It does not have to work, just to demonstrate the desired API.

[Toflar]

Sure! So my goal is to re-use the Symfony HttpClient and EventDispatcher registered in the container. This gives me the tools needed to register events via the regular dependency injection container and because the fullstack framework decorates both services in the dev enviroment, you can collect and inspect data in the Symfony Profiler.
In my case, I want to build a GUI for users to configure their integrations themselves so I need to build the final configuration for Instructor myself. It looks like at the moment this is the LLM class but I don't really mind how it's called 😊
Hence, I have factories - each one being responsible for a certain AI provider (OpenAI, Anthropic, Ollama etc.) with whatever configuration they need. So something along the lines of this:

use Cognesy\Http\Drivers\SymfonyDriver;
use Cognesy\Polyglot\LLM\Data\LLMConfig;
use Cognesy\Polyglot\LLM\LLM;
use Psr\EventDispatcher\EventDispatcherInterface;
use Symfony\Contracts\HttpClient\HttpClientInterface;

class OpenAIProviderFactory implements ProviderFactory
{
    // Existing Symfony services injected via DI
    public function __construct(private HttpClientInterface $httpClient, private EventDispatcherInterface $eventDispatcher) {}

    public function createLLM(array $config): LLM
    {
        // The $config array is just as an example, it represents the config coming from my GUI.
        
        // Configure whatever is necessary for this integration (OpenAI specific config)
        $llmConfig = new LLMConfig(
            provider: 'openai',
            apiUrl: 'https://api.openai.com/v1',
            apiKey: $config['api_key'],
            temperature: $config['temperature'],
        );
        
        // Return some object that contains all the info needed to interact with Instructor via the Symfony HttpClient and its EventDispatcher
        return new LLM($llmConfig, new SymfonyDriver($this->httpClient, $this->eventDispatcher));
    }
}

I then have a number of those factories for all the providers I built a GUI for and I have an array of "transformers" that are able to load and apply changes to any type of model (resource) of my Content Management System. So e.g. one transformer can transform an image with its metadata, one transforms a text element, the other transforms a table element etc..
I would then use the factory more or less like this:

class MyCentralAIService
{    
    public function transform(TransformerInterface $transformer, ProviderInterface $provider, object $source, object $target, string $prompt): void
    {
        $sourceModel = $transformer->loadModel($source);

        $transformedModel = (new StructuredOutput())
            ->withLLM($provider->getLLM()) // This essentially has to contain everything that is configurable on the AI integration side
            ->withInput($sourceModel)
            ->withResponseModel($sourceModel)
            ->withPrompt($prompt)
            ->withOutputMode(OutputMode::Json)
            ->create()
            ->get()
        ;

        $transformer->applyModel($source, $target, $transformedModel, $prompt);
    }
}

[ddebowczyk]

Would you be able to check current (unreleased) code from main branch on instructor-php repo?

It is heavily modified, but I am not releasing it yet as some work is still not finished.

It should be able to support your needs, unless I miss something. Check this example using new API:
Structured outputs - https://github.com/cognesy/instructor-php/tree/main/examples/A02_Advanced/CustomClientParameters/run.php
Just inference - https://github.com/cognesy/instructor-php/blob/main/examples/B02_LLMAdvanced/CustomClientParameters/run.php

Please note that HttpClient class is necessary as underlying HTTP client adapter (which provides some extra capabilities like debugging or buffering).

[Toflar]

Thanks! I now used https://github.com/cognesy/instructor-php/blob/main/examples/B02_LLMAdvanced/CustomClientParameters/run.php as reference but what I'm getting is Settings file not found: .../config/structured.php. So it still seems to require some config files to be present although I want to create everything on-the-fly.

[ddebowczyk]

:(
Corrected

[Toflar]

Cool, that's fixed! Now I'm getting Unable to use the "Symfony\Component\PropertyInfo\Extractor\PhpDocExtractor" class as the "phpdocumentor/reflection-docblock" package is not installed. Try running composer require "phpdocumentor/reflection-docblock".. So I guess either this has to be optional or you have to add the requirement, in case it is actually required?

[ddebowczyk]

Good catch, thanks.

[Toflar]

Just updated to the latest commits again (let me know if I should wait). Now I'm getting

Configuration resolution failed for preset ''. Attempts made: - provider[0]: failed - No default preset found for http.defaultPreset: Settings file not found: .../config/http.php Exceptions encountered: - No default preset found for http.defaultPreset: Settings file not found: .../config/http.php To allow empty fallback configs (not recommended), call allowEmptyFallback() on the ConfigSource.

Not sure if I should do this because the call is also not present on https://github.com/cognesy/instructor-php/tree/main/examples/A02_Advanced/CustomClientParameters/run.php which is still the example I'm following :)

[ddebowczyk]

Yes, main is unstable - I am aware of the issues and working to fix them.

[ddebowczyk]

I've committed a working version, but be aware that things are still moving around.
I hope that the new DX will be worth it :)

[ddebowczyk]

Check this:
https://github.com/cognesy/instructor-php/tree/main/examples/A02_Advanced/ConfigProviders
and
https://github.com/cognesy/instructor-php/tree/main/packages/config/src/Providers

[Toflar]

Yeah but don't you agree that it would make sense to do that either by default or have some helper? Because, yes, I can set that myself in my project. But I'm building a bundle that again, is installed somewhere where I don't know if the directory is called vendor or they renamed it using the Composer vendor-dir configuration value to something else. Whereas you have complete control over where the files are because you can use __DIR__ and make it relative to e.g. the location of the Settings class.
Or in other words, it's way harder for me to find out the $path to your default config directory than it is for Instructor itself.

[ddebowczyk]

Got it. Let me think how to approach it.
Part of the problem is my mental model. I expected those config files will need to be edited by the user.

[Toflar]

I see, I have to admit that I quite like the "overrides" approach. This is how I see it:

• You cannot have no configuration, otherwise you run into errors like I did (no preset for structured group).
• As having no configuration at all is not possible, it means you should ship defaults.

Simple as that 😊

What if we always load the settings from ./config in Instructor and then instead of having ->withLLMConfigOverrides(['apiUrl' => 'https://api.openai.com/v1']) we'd have something like ->withConfigOverrides('llm', ['apiUrl' => 'https://api.openai.com/v1'])?

Then users can still adjust all properties but you cannot run into a no <x> configured error because you always have a sensible default?

[ddebowczyk]

OK, from 1.0.0-RC17 the Settings class checks:

• the path set explicitly via Settings::setPath()
• multiple paths provided via env variable INSTRUCTOR_CONFIG_PATHS
• if it's missing - it uses internal default paths: first main dir config, then vendor/cognesy/instructor-php/config,....

I think this should achieve what you expected.

[Toflar]

Nice, that works perfectly! Thank you, Dariusz!
Two hints:

• Most people won't adjust the name of vendor but you can. So instead of hardcoding vendor, you might want to make it relative to any PHP class of your project. That way, it can reside in any folder.
• I noticed that when I require ^1.0@rc, I get RC13 and not RC17. This is because the tag 1.0.1-rc13 still exists and is synced (https://github.com/cognesy/instructor-php/releases/tag/v1.0.1-RC13) - and of course, 1.0.1 is higher than 1.0.0. I'm assuming this was a typo and you fixed it later but it seems like you have to delete this tag and force a sync over at packagist.org 😊

[ddebowczyk]

1.0.1-RC13 was a typo indeed. I will remove it from the repo. Thanks for flagging this.

[ddebowczyk]

Check if now it works, thanks again.

[Toflar]

Looks good now, thx!