Is Key module really a dependency?

I think this should actually be against the AI module. OpenAI provider (along with most other providers) do make use of key.

However AI, which is where the explicit dependency is, doesn't directly use it. In the case of the AWS Bedrock provider, key is never used as it makes use of the AWS module's profiles to manage the credentials.

I think this might be more involved that just removing the dependency, because the KeyRepositoryInterface is explicitly referenced in the construct statements for AiVdbProviderClientBase and AiProviderClientBase and so even providers that don't use Key to save the credentials will still break if it isn't there.

This will probably require refactoring so that Key becomes an optional dependency and the KeyRepositoryInterface can be nulled .in the provider constructs.

It would be good to get some maintainer feedback on whether that's a good idea before we do anything though.

It's still valid for every provider that defined a dependency on Key but never uses it.

Not sure I follow you @mglaman.

Let me clear that haphazard comment up, sorry!

I opened this for the OpenAI provider because it duplicates the dependency on `key` from the `ai` module and that module's provider doesn't even leverage code from Key provided by the base provider class. I'm 99% certain it's the same case for the AWS Bedrock Provider as pointed out in #3.

There is some triage which could be done in the modules and it doesn't have to just happen here as a big refactor. That's why I didn't open an issue here to start with. But this could be a plan/meta and then the provider modules adjust accordingly.

This is an odd situation caused by the providers being moved into individual contrib modules I think: the AI module itself provides the base provider that requires a KeyRepositoryInterface to create any new provider, and provides the base loadApiKey() method that they uses the KeyRepository. Given that the code using the key module lives in the AI module, there's an argument the requirement is in the right place.

So code-wise the AI module contains nothing that requires Key, but the provider could be relying on the AI module to pull it in for methods it implements without the word KeyRepository ever appearing in its code. (OpenAI for example does rely on the Key module for storing its keys in its settings form, but doesn't have any code using it in its provider because this is inherited from the base module's code).

It's going to be tricky to implement a solution that doesn't break anything else, and the work may well need to be carried out and co-ordinated across a number of different codebases at the same time.