Global configuration for project commands #4888
Conversation
|
AppVeyor failure looks legit. |
|
This seems to be a more elaborated version of the idea in #4840. This definitely looks better. I will rebase the haddock stuff on this one I think. |
The failures look related to changes in master since I started this branch. I will rebase. |
|
/cc @dcoutts |
The global configuration in ~/.cabal/config or CABAL_CONFIG should be applied to all packages, even in the project (new-*) commands. Previously, package configuration fields applied only to packages in the actual project. A new field (projectConfigGlobalPackages) is added to ProjectConfig to track the global package configuration. See also: haskell#3883, haskell#4646
loadExactConfig will load just the config in the given file path or return nothing if the file does not exist. loadRawConfig will continue to load the user config in ~/.cabal/config or the file specified by CABAL_CONFIG. loadExactConfig is factored out so that the same logic may be used to read config files from other locations.
If there is a cabal.config.local file in the project root directory, readGlobalConfig reads it after ~/.cabal/config. This is intended to allow the user to specify site-specific global options on a per-project basis. Global options cannot be specified in cabal.project.local, which applies options only to packages in the project. See also: haskell#3883 haskell#4646
The messages specifying the config file path source and which config files are loaded had `notice' verbosity, but they are lowered to `debug' because it is not likely that the user routinely needs this information.
|
@dcoutts promised to review this, so this is blocked on him for now. |
|
I have some concerns about the approach. I'll get back with a proper review. |
@dcoutts |
|
Since I haven't heard anything on this pull request in 3 weeks, I have had to find other ways to get cabal-install working on NixOS. Therefore, I am abandoning this PR in favor of tasks that are worth my time. |
|
Sorry to hear this! @dcoutts, any chance you can find some time to look at this PR? |
|
I'd like us to move in the direction of making config inclusions explicit, and this PR (though well motivated) is taking us further in the direction of implicit ad-hoc hard to understand/explain inclusion rules.
For example, if we want these kind of things then we should allow it to be explicit, e.g.
This is a good idea, but it needs corresponding syntax in the
I don't think we should be reading the legacy
They can now be specified in |
|
I'm +1 on the idea of explicit includes, but I'd like to see the proposal spelled out in more detail.
It's not very clear from this example what the proposed semantics of |
Commits
Two deficiencies described in #3883 are corrected:
cabal.projectoffers no mechanism to specify project-wide global options.Apply global configuration to all packages in project commands
The global configuration in ~/.cabal/config or CABAL_CONFIG should be applied to
all packages, even in the project (new-*) commands. Previously, package
configuration fields applied only to packages in the actual project. A new
field (projectConfigGlobalPackages) is added to ProjectConfig to track the
global package configuration.
See also: #3883 #4646
readGlobalConfig: Also consider cabal.config files in project root
If there is a cabal.config.local file in the project root directory,
readGlobalConfig reads it after ~/.cabal/config. This is intended to allow the
user to specify site-specific global options on a per-project basis. Global
options cannot be specified in cabal.project.local, which applies options only
to packages in the project.
See also: #3883 #4646
Checklist
If the change is docs-only,[ci skip]is used to avoid triggering the build bots.Testing
I tested these changes by implementing #4646 in terms of global configuration files.