I agree with removing the full copy to defaults to config.yaml. this lead to a lot of issues. however removing the config.yaml completely, I am not sure about. it is quite breaking (which should be fine as this is our policy in pypsa-eur). just to get the rationale: The idea is that the user always sets a --configfile argument in the snakemake call as soon as they want to divert from the default?

So you would remove the complete default copy, but keep configfile: "config/config.yaml" in the snakefile? So if people want to avoid passing --configfile on every run, they can still manually create and use that file?

Sounds good to me. You would still have the fourfold chain if you pass your own config file, and it is not super obvious that a config.yaml that does not even exist in the repo is being read in, but probably worth it for the convenience. Also makes this change less breaking

@lkstrp Is there any update on this?

No, we just need to choose one of the two options:

1. Remove config.yaml completely; you would always need to add --configfile as a flag
2. Remove config.yaml from the repository, but keep it in the chain so that it can still be used without adding a flag

I guess people would prefer the second

No, we just need to choose one of the two options:

1. Remove config.yaml completely; you would always need to add --configfile as a flag
2. Remove config.yaml from the repository, but keep it in the chain so that it can still be used without adding a flag

I guess people would prefer the second

I personally find that having config.yaml in the chain can be quite annoying and also confusing, especially, for first time users (because it often happened by accident that the config.yaml is in there as an outdated copy of the default config) which leads to problems.

I think we should remove the copy behaviour as @FabianHofmann already suggested, but we could keep the config.yaml in the chain but have it as an empty custom config file per default. This way by default it does not overwrite anything but only does so if the user explicitly adds anything inside this custom config? We could even rename the file per default to something like: config.custom.yaml or some similar naming.

tl;dr I agree with the upside of option two if the copy behaviour is removed

So you would remove the complete default copy, but keep configfile: "config/config.yaml" in the snakefile? So if people want to avoid passing --configfile on every run, they can still manually create and use that file?

This sounds like the best compromise. The important aspects to me are:

• No requirement to pass --configfile
• Untracked config.yaml file. (Otherwise, I bet most PRs will have contributors config)
• No renaming so it's not breaking.
• Agree to remove default copy.

This is good to go now