Allow developers to decide whether to use env vars for API keys or not

[Tochemey]

Is your feature request related to a problem? Please describe. Current I have observed that one need to set API kEY (either for claude, etc...) as env vars before calling those APIs. This is ok, however it is not scalable because it forces developers to set an environment variable. Some companies do not use env variables due to security concerns.

Describe the solution you'd like I will suggest passing those keys as parameters and let the developer decide how he/she would like to set them or use them. For instance openai.New(apiKey string) should suffice.

[henomis]

You can use the method WithClient(client *openai.Client) *OpenAI to solve your issue

[Pencroff]

Hi Simone,

I agree with the ticket starter's suggestion.

Upon reviewing existing implementations of the llm package, I noticed that all original clients (e.g., go-openai, cohere-go) as well as current implementations like huggingface or anthropic use a secret as a parameter. This includes libraries such as liushuangls/go-anthropic and the origin alpha implementation anthropic-sdk-go.

To align with these existing patterns, I suggest adding the possibility to set a secret header for ollama, especially considering it can be run on remote servers (ref: #849).

If you're willing to accept this change, I'd be happy to create a pull request. Please note that this would require a breaking change and a new version.

The updated New() calls in the llm package would take the form of New(secret string), with other parameters configured using the corresponding With... methods of the builder.

[henomis]

Just to avoid breaking change, we could try to create a new constructor like NewWithSecret(secret), or maybe try to understand if it is possible to attach WithSecret method and recreate the internal http client.