Implement Modular Settings Architecture #12
Description
Description:
Refactor settings system to be modular and extensible for different configuration types.
Requirements:
- Separate settings classes for different components
- The ones I can think of now include the LLM providers, the path settings, settings for Hatchling's chat mode, settings controlling the tool calling. There are probably others
- A registering system.
- The list of settings itself can probably be hardcoded by the data models (I don't see an application where we would want to let the user register custom new settings at this point)
- But data models must be discoverable such that a constructor function can instantiate all the appropriate set/get CLI-commands
- An easy way is probably to have only one command but a convenient accessor to all setting names
- To be brainstormed more :)
- Environment variable override support for relevant settings (mostly paths)
- CLI commands to control values