feat: improved CLI and configuration handling

[teto]

Is your feature request related to a problem? Please describe.

everytime I have to run localai, I have to pass it several flags like the listenAddress, the models-path and so on. These rarely changes and I would like to just record them so that I can just type localai.
Some (all?) of them can be passed via environment variables but I dont like that, it pollutes the env (especially as some variables are not even prefixed with LOCALAI, is more implicit. Having a config.yaml I could edit would be much better. I just found out about --localai-config-dir` but it doesn't seem to be able to load the models-path for instance ? I had a look at the code and I think localai just watches that folder for api keys and tokens ?

Describe the solution you'd like
localai loads its flags/configuration from a configuration file (e.g. config.yaml). Ideally localai would look into $XDG_CONFIG_HOME/localai (e.g. ~/.config/localai/)

Describe alternatives you've considered

Export all the environment variables.
One could also create a wrapper or alias but because I intend to hack on localai, that might not be easy either

Additional context

I also find the --help for --localai-config-dir not descriptive enough of what it does

[cryptk]

Currently LocalAI uses the urfave/cli package to build the CLI for the application. It looks like it can be extended pretty easily to allow loading the config from a YAML file: https://cli.urfave.org/v2/examples/flags/#values-from-alternate-input-sources-yaml-toml-and-others.

Unfortunately after testing this route, it appears that if we provide a default value for the config file location using the altsrc functionality, that makes the configuration file mandatory. While we might be able to work around this by creating a closure that wraps around the required functionality checks for the presence of the file first, I'm curious if that time may be better spent by moving the project to something like cobra and viper for CLI and configuration handling.

For what it's worth, if we do NOT provide a default file path, then everything works as you would expect, but it means that in order to use a config file, your invocation would need to be something like ./local-ai --yamlConfig /path/to/config.yaml as opposed to being able to just call ./local-ai and having it figure it out.

Going to wait on this one until I get some clarification from @mudler about which way he would prefer we go with this one.

[mudler]

I do agree a form of configuration either YAML, json, TOML (or all of them?) makes totally sense.

Additional context

I also find the --help for --localai-config-dir not descriptive enough of what it does

Good point, first we should improve documentation/help around that

Currently LocalAI uses the urfave/cli package to build the CLI for the application. It looks like it can be extended pretty easily to allow loading the config from a YAML file: https://cli.urfave.org/v2/examples/flags/#values-from-alternate-input-sources-yaml-toml-and-others.

Unfortunately after testing this route, it appears that if we provide a default value for the config file location using the altsrc functionality, that makes the configuration file mandatory. While we might be able to work around this by creating a closure that wraps around the required functionality checks for the presence of the file first, I'm curious if that time may be better spent by moving the project to something like cobra and viper for CLI and configuration handling.

I have a mixed feeling on viper/cobra, almost all my other projects used previously viper/cobra, but it ended it to be always more complex for what was actually the need/use case and I ended up always regretting it.

I'm not against it, however I'd be careful in considering it first, especially if urfave/cli already supports loading from other files.

There are also out there good alternatives, which might be worth considering too, I know at least 2 of them:

• https://github.com/alecthomas/kong
• https://github.com/knadh/koanf

A side note: I think manual, obvious wrappers are fine and good enough to maintain as tends to be more readable then having hidden complexities which anyone would need to learn a framework first before being able to understand.

[cryptk]

So far, I think I'm liking Kong more just from reading through their docs. It also appears to have good support for loading from a config file, has sub-commands, flags, envvars (including a nice example using godotenv to support loading from a .env file), etc. So it should cover everything we are currently using urfave/cli for, but with better support for config file loading (specifically not dying if a default config file path does not exist).