ApiAssistant abstract base class for assistants that don't require an API key

[smokestacklightnin]

Feature description

Previously, we only had assistants hosted nonlocally. Now, adding Ollama, we will be supporting local assistants. The remote assistants all required API keys, but local ones like Ollama do not. That is really the only substantial difference; Ollama still is accessed via a REST API. Does it make sense to others to refactor ragna.assistants._api.ApiAssistant to not require an API key and then subclass it with the newly created subclass requiring the key?

An alternative is subclassing ragna.core.Assistant from "scratch" and not requiring an API key. This option seems suboptimal to me because all the behavior is otherwise the same as ragna.assistants._api.ApiAssistant.

Another alternative is to override the requirements to remove the API key requirement.

Value and/or benefit

No response

Anything else?

No response

[smokestacklightnin]

@pmeier Do you have an opinion?

[pmeier]

Now, adding Ollama, we will be supporting local assistants

To give some context here: this is not decided yet. We are exploring this an option.

Does it make sense to others to refactor ragna.assistants._api.ApiAssistant to not require an API key and then subclass it with the newly created subclass requiring the key?

So far the new Ollama assistant is the only outlier. Thus, I wouldn't break our abstraction just yet, given that a workaround is available (see below).

In case we encounter 1 or 2 more exceptions (maybe vLLM) to our current rule, I indeed agree it would make sense to refactor the class. I would move the API key functionality to a class AuthorizedApiAssistant(ApiAssistant) (name TBD) subclass.

An alternative is subclassing ragna.core.Assistant from "scratch" and not requiring an API key. This option seems suboptimal to me because all the behavior is otherwise the same as ragna.assistants._api.ApiAssistant.

Another alternative is to override the requirements to remove the API key requirement.

Of those two, I would vote for the latter. That is a simple enough workaround that can easily be removed if we go for the more general solution explained above in the future.