Allow checking configuration for api client

[jonallured]

Over on Roast I was interested in adding some logic to skip creating an api client when one has been provided via an initializer so I came here to see what that would look like. Turns out it's pretty easy so I thought I'd see about making this change up here.

[obie]

@jonallured can you revisit this PR when you get a chance please?

[jonallured]

Ok @obie this has been updated with latest main. Can you approve the workflow so that the CI actually run please? 😝

[obie]

where is this used?

[jonallured]

I was using this method inside of Roast to avoid clobbering the client that was being set in an initializer. So the use case was:

• if the config already has a client, bail
• if the config does not have a client, then check for an env var and make the right client

That was here Shopify/roast#65 but that PR was closed and the underlying issue was addressed in a different way. That could mean that this PR is also no longer needed - happy to close if you feel like this is not needed!

I did just take a look at how this is working in Roast today - so much has changed since I opened this PR! 😝 But you can see that Roast is pretty knowledgeable about how Raix works:

https://github.com/Shopify/roast/blob/main/lib/roast/workflow/workflow_initializer.rb#L120

What I think is better encapsulation would be for the config to answer the question of "are you already configured with a client?" so that Roast could look more like this:

      def configure_api_client
        # Skip if api client is already configured (e.g., by initializers)
-       return if api_client_already_configured?
+       return if @configuration.client?

WDYT?

[ujh]

The question is how that interacts with https://github.com/OlympiaAI/raix?tab=readme-ov-file#global-vs-class-level-configuration, where you can already set a client (or any other config option) either on the global level or the class level. Here the one configured on the class level currently takes precedence. I do wonder if that is the same use case, i.e. different clients for different agent classes or if you want something else?