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.

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 :)

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?

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