Fix #6606 Distinguish global and project-level configuration files

[mpilgrem]

Also refactors where:

• 'project' is used to refer to a file or directory that may not be within a project directory but within the Stack root; or

• stackYaml is used to refer to a configuration file that may be a global one as well as a project-level one.

• Any changes that could be relevant to users have been recorded in ChangeLog.md.

• The documentation has been updated, if necessary

Please also shortly describe how you tested your change. Bonus points for added tests! Relying on CI.

[philderbeast]

As this includes a renaming, would it make sense to drop Yaml altogether in those names and go with more meaningful names, something like Project* versus Global*, where * is something like Config or Settings?

[mpilgrem]

@philderbeast, I am open to suggestions on naming of the field of the BuildConfig constructor - I think everything else flows from that choice. At the moment, Stack has:

• at most one project-level YAML configuration file, named stack.yaml by default but can be any *.yaml file; and
• a user-specific global YAML configuration file, named config.yaml in the Stack Root; and
• (according to the documentation; I need to check the code to see if that is correct - EDIT: see further post below) perhaps, system-wide global YAML configuration file, named config.yaml in /etc/stack (but that is a Unix-like file path?).

I picked yamlFile for the path to the YAML configuration file because what *.yaml and config.yaml had in common was the 'YAML' part. The problem with configYaml or, even, configFile is that people might assume it refers to config.yaml only, given the 'config' part. The problem with settingsFile or settingsYaml is that the term 'settings' is not used anywhere else to refer to these files.

[mpilgrem]

Looking at Stack.Config.loadConfig and:

extraConfigs0 <- getExtraConfigs userConfigPath >>=
    mapM (\file -> loadConfigYaml (parseConfigMonoid (parent file)) file)

the 'extra' global configuration files are under- or un-documented on online. I'll raise that as a separate issue.

[mpilgrem]

@philderbeast, on reflection, I decided to prefer configFile to yamlFile and, where applicable, use Right projectConfigFile ->.

[philderbeast]

Your choice of ConfigFile aligns with Cabal naming a similar thing ProjectConfigPath¹.

Footnotes

1. YAML can't do imports but Cabal's projects can so that is why it is a path and not a file over there. ↩