Implement a Unified Configuration File for Project Settings

[similato87]

Feature description

I propose the implementation of a general, unified configuration file in TOML format for the gpt-engineer project. This configuration file would serve as a centralized repository for various project settings, including but not limited to:

• API keys for OpenAPI and the corresponding model configurations.
• The switch for linting.
• File extension settings for the git filter.
• Parameters for self-healing mechanisms in code, such as retry times (e.g., 0-2).
• Other settings as suggested by community contributors to enhance flexibility and functionality.

The file should be persistent on the disk and should be presented to users upon each run of the application. While users will be encouraged to review and modify the settings as needed, they will not be forced to make changes. The system should offer the option to open this configuration file with the user’s default editor, with a simple bypass option that proceeds without opening the file but notifies the user of its existence and purpose.

Motivation/Application

Currently, the project has several configuration files managing different aspects of the application. Having a single, unified configuration file would simplify the management of these settings and enhance the maintainability of the codebase. This approach would also streamline the user experience and provide a clear, consistent method for setting and reviewing configurations.

The proposed configuration file in TOML format ensures readability and ease of use, aligning with modern best practices for configuration management. By reducing the complexity and fragmentation of configuration management, we can improve both developer and user experience, facilitating easier updates and modifications as the project evolves.

Request for Community Input

I invite all contributors to suggest what additional configurations might be relevant for inclusion in this unified file and to propose ideas on how best to implement this feature. Your insights and expertise are invaluable as we work to make this enhancement beneficial for everyone.

Policy and info

• Please note that issues not updated or commented on within 14 days will be considered resolved and closed by maintainers if they contain adequate responses.
• To streamline certain enhancements, consider using the "sweep" label, which helps in converting issues directly into coded pull requests, as detailed here: Sweep Documentation.
• Contributors new to the project are encouraged to take this up as a "good first issue," which, while straightforward, is essential for the project’s ongoing development.

[similato87]

Hi @ATheorell,

Could you please review the proposed feature description for the general config file? Does it align with your expectations, or do you have alternative suggestions? Your insights are invaluable to the development of this feature.

As a preliminary step, would you recommend creating a config.toml in the project root directory? This would allow the gpte command to load configurations at the first step when executed. At the same time, I plan to deprecate both the env and the env template. Users would be required to configure all settings, including API keys, prior to the initial run.

[ATheorell]

First of all, thank you so much for pushing a comprehensive discussion about this very needed feature @similato87 :)

Some thoughts:

• I propose we use the existing (but currently unused) project_config.py for parsing the config. It will probably need some edits.
• I agree that we should create a default config in the root folder. As a guiding principle, the default config should be detailed enough that if a new user leaves it untouched, gpt-engineer behaves like it does today. Modifying the config or writing a new config should only be necessary for more advanced use-cases.
• The path to the config file should be written at the start of the gpte run, so that users know where the options come from.
• As you say, it would be great to have a white list for some folders (like "projects") so that these folder are added to improve calls, even if they happen to be on the .gitignore.
• We should consider moving some command line arguments to the config file to make the cli interface easier to overview.
• Great idea with setting algorithmic parameters!
• Regarding .env file. I don't think we need to deprecate that, or the use of a pre-set environment variable to an API-key. Instead the config should just offer one more avenue to set the API key. It should be unset by default. The idea here again is to not force current users to change their workflow.

More things will probably pop up along the way :)

[similato87]

Hi Axel and Erik,

First, thank you, @ATheorell , for reminding us about the existing configuration handling, and @ErikBjare , for providing the initial project_config.py. It's a solid foundation, but we might need to make some adjustments to use it as our configuration utility library effectively.

I fully agree that we should maintain our current behavior to avoid confusing our users. However, I suggest we also offer an alternative approach for those who might prefer to set up API keys and other parameters in a single file. Some users may appreciate the simplicity of having all configurations in one place. We can introduce this option in the README while preserving the original logic for existing users.

Axel, I'd like to hear your thoughts on the sections for the unified configuration file. Specifically:

• Model Settings: What parameters do you think should be included here? Can we let the users choose what model to use instead of always sticking to the latest one?
• Code Generation and Improvement: What configurations should we support in this section?
• Command Line Configurations: What else do you think we should cover in terms of CLI settings?

[ATheorell]

As we discussed in the meeting, I think the config should include defaults for all, or nearly all of the cli arguments.