New Feature: Add support using a TOML "dotfile" config file in the user's homedir

[mulla028]

Description

Your tool is capable of specifying the default values, using flag arguments such as: api-key or the model. However, It would be so practical to add a file that will store all these variables in the single file, that would be possible to modify manually or using flag arguments like: --api-key and --base-url, it would override that file automatically, applying the values that user specified.

While you have .env file for the application configuration, I highly suggest you to try TOML configuration, for the reason, that it provides reach-feature capability to set and manage complex configurations.

Hope you will find it helpful, and I would love to work on this issue, assign it to me, and I will create a draft pull request, where you would be able to monitor all the changes before you merge them 💯

[theoforger]

Thanks for the suggestion!

Just a question. How do you plan to prioritize different configurations? Since now we have:

• Command line arguments
• Environment variables
• A config file

Good luck on the PR ❤️

[mulla028]

Thanks for the suggestion!

Just a question. How do you plan to prioritize different configurations? Since now we have:

• Command line arguments
• Environment variables
• A config file

Good luck on the PR ❤️

Thank you for asking a good question!

• Idea is that since we have .toml file, we don't need .env. How do you look at getting rid of .env file; for the reason, that is pointless to have these two files together. They both play the same role, but TOML is way better option.
• On the paper it looks like if we have a config file and the command line arguments aren't provided, the tool will look at config.toml. However, if arguments were provided to specify variables (e.g., -a <key> ), It would simply override the config file using the provided key.
• If config file is missing, we just print an error because it wouldn't be able to get these variables

Hope all above makes sense to you, if you have any other questions, feel free to leave comments 🗣️

[theoforger]

Idea is that since we have .toml file, we don't need .env. How do you look at getting rid of .env file

I'm more inclined to keep the environment variables since they can be useful for automation.

Everything else sounds good though. Maybe just focus on the config file and arguments for now? I'll consider environment variables later.

[mulla028]

Idea is that since we have .toml file, we don't need .env. How do you look at getting rid of .env file

I'm more inclined to keep the environment variables since they can be useful for automation.

Everything else sounds good though. Maybe just focus on the config file and arguments for now? I'll consider environment variables later.

By the way, what do you think of specifying model? Since your tool has an option of usage bunch of models at once. How should it go to the .toml file? Of course, at first I will start for implementation of api-key now. Just looking a little bit ahead.

[theoforger]

By the way, what do you think of specifying model?

Same as the environment variable: You specify one default model in the config file. If -m option is not set, the default one gets used.

Calling multiple models at once is only supported through the -m option.