Setup lwe with non-default provider about llm-workflow-engine HOT 4 CLOSED

It's unclear where I supposed to get it? Create empty? Create with some defaults?

https://llm-workflow-engine.readthedocs.io/en/latest/configuration.html#editing-the-configuration-for-the-current-profile

Running lwe config files will also show you the location of the config file, should you wish to edit it manually.

To run lwe (or even lwe config!!) I still need OPENAI_API_KEY, but why? What if i have not one?

OpenAI is used by default to auto-generate titles for conversations. This can be overridden in the config by setting backend_options.title_generation.provider if needed.

The chat_openai provider is currently always loaded by LWE core, which is probably why you'd get an error about a missing OpenAI API key. I think this approach is sensible for most users, and I'm not interested in doing the work to change it. I would consider a well-formed PR to allow the chat_openai provider to be completely optional.

And when I have googleai plugin installed, I need also GOOGLE_API_KEY env var to be always set_ otherwise lwe does not even start.

I fail to see why this is an issue -- the API key is required to use the plugin. If you need to start LWE before you have a Google API key, then disable the plugin until you have properly exported the key to your environment.

So: I suppose there is no sense to demand api keys before they actually be used in request.

The keys are required by the underlying libraries that LWE leverages, and these libraries must be loaded via the plugin system on bootstrap.

Though I have managed to achieve that via OPENAI_BASE_URL env var, that is not enoug, as i would like to have several different profiles, each with own base_url and api_key.

The way to do this is to use presets: https://llm-workflow-engine.readthedocs.io/en/latest/presets.html

Presets will allow you to set up and save different configurations, and easily switch between them, or use them in templates/workflows.

There was already support for adding openai_api_key and openai_organization to presets, and I just pushed the feature to be able to add openai_api_base to a preset for OpenAI providers as well.

Keep in mind this new feature is completely untested, but as the underlying library supports it, I do think it should work.

from llm-workflow-engine.

Running lwe config files will also show you the location of the config file, should you wish to edit it manually.

Right, and there is complete directory structure, but empty. Only directories, without files.

I fail to see why this is an issue -- the API key is required to use the plugin. If you need to start LWE before you have a Google API key, then disable the plugin until you have properly exported the key to your environment.

Well, this is just not user-friendly. Sure some persistent user (like me) can overcome all such minor obstacles. But some other user just will not spend time for this (and even more so to report it).
For my case: I want to have all plugins installed and available to use.
But my environment is not persistent, I set api keys only when I use tools that require them.
I will try to use presets instead, but.. I still see that as issue. May be minor.

from llm-workflow-engine.

Right, and there is complete directory structure, but empty. Only directories, without files.

LWE doesn't need a config file to run, it will run w/ defaults if one does not exist IIRC. Once you create a config file either via /config edit, or manually, then LWE will use that to override the defaults.

Well, this is just not user-friendly. Sure some persistent user (like me) can overcome all such minor obstacles. But some other user just will not spend time for this (and even more so to report it).

You are the first user to ever report this issue. All the installation instructions instruct you to set the API key first.

But my environment is not persistent, I set api keys only when I use tools that require them.

This is clearly not a typical use, but a use more in line with a power user. And a power user can easily adjust their workflow to automate an issue like this, such as setting dummy API keys by default, then overriding them when needed.

And again, to clarify, it is NOT LWE that is enforcing the requirement of API keys -- it's the underlying libraries. Sure it's theoretically possible to re-architect things to probably overcome that reality, but it would most likely make the code much more complicated, bug-prone, and harder to reason about. IMO the juice isn't worth the squeeze, especially given that I provide this code for free, in my spare time ;)

from llm-workflow-engine.

I think I've addressed everything in this issue. As I said, I'll consider a well-formed PR to create better abstractions for loading components if one is submitted.

from llm-workflow-engine.