Per-component settings in cabal.project and separation of concerns
- Dominant language
- Haskell
- Stars
- 1.7k
- Forks
- 750
- Avg merge
- 4d 3h
- Merged PRs (30d)
- 28
Description
TL;DR There is currently no way, apart from editing the `.cabal` file, of setting per-component settings. However, some development settings need this granularity, eg warnings.
Some of the settings in `cabal.project` aren't necessarily one-size-fits-all for all the components in a project. For example, in a project with a much larger frontend than core, it would be a waste to turn on profiling globally when it's only the core that will be responsible. For another, some components might be unfixably broken wrt some warnings, but that doesn't mean those warnings aren't useful elsewhere in the project.
Hence, the request for per-component settings in `cabal.project`.
(In general, it seems that `.cabal` serves to hold the packaging metadata (e.g. `build-depends`, `version`) whereas the `cabal.project` files serve to hold the development metadata (e.g. `tests`, `jobs`, `profiling`).
(Note that if this interpretation is correct, it might be helpful to nudge users to separate their settings along these lines)
Unfortunately, `ghc-options` includes a bit of both. You have eg the `ghc-typelits-*` compiler plugins that are definitely packaging metadata, but by the same token `ghctags` is definitely development metadata. You have optimizations that might be important for the package to satisfy its performance promises, but you might also want to disable certain expensive optimizations at dev time. Moreover, note that some of these only make sense per-component, while others can and should be set as projectwide defaults.)
One actual usecase where this has bitten me is that I've disabled certain warnings in my `.cabal` because the relevant components are unfixably broken with them. However, those warnings are useful in the other components. I can't currently just enable the warnings in `cabal.project.local`, since that overrides the warnings I've set in `.cabal`. Moreover, these warnings not being part of the packaging metadata, they have no business being in `.cabal`.
But if I could set per-component settings, I'd be able to extract them into `project.cabal` and then (assuming overrides follow some form of a specificity rule) just enable the relevant warnings globally in `project.cabal.local`.
Contributor guide
Assessment
This issue has not been assessed yet.