I wonder in the first place why we enforce loading a configuration file if it is not there. I mean, there is an easy solution to this: if the config file does not exists, do nothing and just use the default config. That's a common pattern for many software, where config files are optional.

The problem, I think, is that this default config file is used mostly as a mean to document the config items and their default value ? Because this list of config items is built dynamically by each sub-package declaring items, there is no centralized version of it, and it does not appear in the documentation as well. But instead of always creating this default config file, we could have a function creating it on demand, and better documentation of the config items.

why we enforce loading a configuration file if it is not there

The original intent is lost on me, but I guess this is for first time installation, so that the cfg file will be where it is supposed to be and user will only have to edit it for customization? Otherwise, there is this extra manual step of "where am I supposed to copy this file to"?

if the config file does not exists, do nothing

We could, but this is a breaking change (maybe for 5.x?) and we cannot backport. It won't solve the problem of people stuck with astropy 4.x and wants to suppress loading it.

Not reading the config file if it doesn't exist would not be a breaking change, since this would be equivalent to reading a config file that was not modified.
What could be a more important change would be to not write this default config file, and instead have a function to create it on demand, at the same place where it is put currently.

I would say "yes" to the side-effect of not loading other config files being acceptable. In some sense these package-specific config files are extending the astropy configuration. The point is to suppress all loading of non-default configurations.

Unless someone else feels strongly about it, I would say "no" to "needs 'what's new' entry". This is mostly useful for development/testing. Its main use to "average" users might be to help them debug issues with their personal configuration, but in this case we can tell them about ASTROPY_SUPPRESS_CONFIG when the need arises. It's also in the documentation so I think that's good enough.

I resolved the latest merge conflicts. I can mark as approved pending successful CI.

Agreed with the logic.

It's been so long that I don't remember where we stand with this anymore. If there is more code change necessary for this PR, please let me know. Thanks!

p.s. Feel free to ping me to rebase after we have fixed all the unrelated CI stuff. Rebased on 2020-10-15

So, am I correct in my understanding that this PR has been superseded by #10877 , @saimn and @astrofrog ?

In my opinion yes, but @astrofrog may think otherwise (see discussion in #10738).

Well, in that case, I don't think this is making it into 4.2. Should we move milestone for both the PRs? (Ah, I see that other PR has a different milestone, so I moved this one's to match.)

No strong opinions from my side, so close if you like :)