Implement modular config system and curses TUI

[davidgantman]

Goal

Introduce a persistent YAML-based configuration system and a modular curses-based text UI into PatchWise.
The config system and TUI will be independent modules, designed so either can be replaced without impacting the other.

---

High-level plan

1. Foundation:

   • Implement a YAML-based config loader in patchwise/utils/config.py.
   • Support loading defaults from default_config.yaml and overlaying with user_config.yaml.
   • No TUI or curses dependencies at this stage.

2. Config options (phase 1):

   • Start with a log_level option in default_config.yaml set to "INFO".
   • Allow user overrides via user_config.yaml.
   • Ensure --log-level CLI flag takes precedence over both configs.

3. Config options (phase 2):

   • Add an api_key_disclaimer section to the default config.
   • No prompting yet — this is just config storage and merging.

4. UI abstraction:

   • Create a standalone curses module in patchwise/utils/curses.py.
   • Must be generic, accepting message and options as arguments and returning a user choice.
   • No direct config file access in this module.

5. Integration:

   • Update main.py to read config at startup, decide when to prompt, and dynamically import curses only if needed.

6. Interactive config editor:

   • Implement patchwise --config to launch a menuconfig-style interface for editing user config values.
   • Display the merged (overlaid) config state — defaults overlaid with user values — and write changes back only to user_config.yaml.

---

Expected outcome

• PatchWise will have a robust, file-based configuration system.
• The curses TUI will be modular and swappable.
• Config values will be respected across runs and adjustable through both file edits and an interactive CLI.

[ethanreidel]

Can work on this.

[ethanreidel]

Just for clarification, you just want a yes/no option for the user when prompted for their OpenAI key? If the user says no, re prompt whenever they next use 'patchwise' in their terminal. If they say yes, store that decision within the configuration file and never reprompt.

[davidgantman]

Just for clarification, you just want a yes/no option for the user when prompted for their OpenAI key? If the user says no, re prompt whenever they next use 'patchwise' in their terminal. If they say yes, store that decision within the configuration file and never reprompt.

@ethanreidel, the options should be "Yes", "No", "Yes and don't show again"

[ethanreidel]

@davidgantman Could you describe each agreement you'd want and when the user should be prompted for each? For example, in PR #33, the user is prompted about their OpenAI key when they use 'patchwise' or 'patchwise --help.'

[davidgantman]

@davidgantman Could you describe each agreement you'd want and when the user should be prompted for each? For example, in PR #33, the user is prompted about their OpenAI key when they use 'patchwise' or 'patchwise --help.'

@ethanreidel, there shouldn’t be a prompt for API key, just a prompt with a disclaimer that PatchWise makes API requests to the specified provider url (default OpenAI’s url) and liteLLM will automatically retrieve their api key from their environment variables (default OPENAI_API_KEY). That’s the only prompt we need at the moment, and the config file should only keep track of whether the user has select “do not show again” which should be false by default and only modified if the user selects “do not show again”.

Let's keep the implementation simple for now, this should be a foundation for future user agreements. We can implement more sophisticated prompts later that are only shown conditionally i.e., only prompting for AI related agreements when an AI review is selected, but let's save that functionality for later. For now the functionality should only be:

flowchart TD
    entry((Entry Points))
    pip[$ pip install patchwise]
    patchwise_help[$ patchwise --help]
    patchwise[$ patchwise]
    check_config{Check config:<br>'Don't show again'}
    update_config["Update config.yaml<br>'Don't show again': True"]
    display_prompt["PatchWise uses LiteLLM, your API key will be<br>used from your environment to make an<br>API request to your specified provider.<br>default: OPENAI_API_KEY<br>Do you acknowledge?<br><br>[YES] [NO] [YES, DON'T SHOW AGAIN]"]
    patchwise_run["run patch reviews"]
    terminate(("Terminate"))

    pip --> entry
    entry ---> patchwise
    entry ---> patchwise_help

    patchwise --> check_config
    check_config -->|"True"| patchwise_run
    check_config -->|"False"| display_prompt
    display_prompt -->|"Yes"| patchwise_run
    display_prompt -->|"Yes, don't show again"| update_config
    display_prompt -->|"No"| terminate
    update_config --> patchwise_run
    patchwise_run --> terminate

    terminate --> entry

Loading

[ethanreidel]

@davidgantman #33 ready for initial review.

[davidgantman]

Another feature: add support for patchwise --config that brings up a Menuconfig style configurator. It should essentially be an easy to use (kernel engineers will be familiar with menuconfig) way to set config options, rather than making them deal with the config file directly. It should also show the overlaid config state (the one that is actually used at runtime.

The overlaid config state (perhaps there's a better term) is the default config overlaid by the user's config. For example:

default_config.yaml:

api_key_disclaimer:
    message: "PatchWise uses LiteLLM to interact with your preferred model provider (default: OpenAI). LiteLLM will automatically retrieve the API key from your environment variables if it is set based on the API url provided to LiteLLM (default: OpenAI). Please confirm that you acknowledge that your API key may be used, if set in your environment. Select 'Yes' to proceed, 'No' to abort, and 'Yes. Don't show again' to proceed and disable this prompt."
    options: ["Yes", "No", "Yes. Don't show again"]
    no_reprompt: false

kernel_url: "git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git"

user_config.yaml:

exclude_reviews: ["Coccicheck"]

kernel_url: "https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git"

Taking the default config and overlaying it with the user config should result in the following config state when running patchwise:

api_key_disclaimer:
    message: "PatchWise uses LiteLLM to interact with your preferred model provider (default: OpenAI). LiteLLM will automatically retrieve the API key from your environment variables if it is set based on the API url provided to LiteLLM (default: OpenAI). Please confirm that you acknowledge that your API key may be used, if set in your environment. Select 'Yes' to proceed, 'No' to abort, and 'Yes. Don't show again' to proceed and disable this prompt."
    options: ["Yes", "No", "Yes. Don't show again"]
    no_reprompt: false

kernel_url: "https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git"

exclude_reviews: ["Coccicheck"]

Note that it is the union of both configs, with the values from the user's config overriding the values from the default config for any configs that overlap.

If the user runs patchwise --config it should display an interactive configurator that displays the current configuration state. If the user modifies a config option, then that should be applied to the user's config file, the default config file should always remain read-only.