Closed georgefst closed 2 years ago
Can this discussion wait for our Vonnegut post-mortem (#704), or do you think it's more urgent?
(FYI the post-mortem is currently scheduled for next Tuesday Aug 3. I may need to push that until I've returned to the UK but let's keep it scheduled as-is for now.)
It's definitely not urgent. I'll add it to my notes for #704.
One annoying thing is that we currently have five identical
default-extensions
lists, for our various components. We could usecommon
stanzas in the cabal files to bring this down to three, but it's still less than ideal. (Roll onGHC2021
...)
There is a reason for this, unfortunately. One of the tools - maybe cabal-fmt, or cabal-edit doesn't support common stanzas. Well, actually it expands them when editing the file.
Generally, I agree with adding more extensions to the cabal file. I haven't looked at the list in detail, so may want to quibble over the exact set.
One annoying thing is that we currently have five identical
default-extensions
lists, for our various components. We could usecommon
stanzas in the cabal files to bring this down to three, but it's still less than ideal. (Roll onGHC2021
...)There is a reason for this, unfortunately. One of the tools - maybe cabal-fmt, or cabal-edit doesn't support common stanzas. Well, actually it expands them when editing the file.
I think practically no Cabal tools support common stanzas.
Some background on the common stanza support: IIRC, cabal itself expands stanzas whilst parsing, and doesn't represent them in its AST of *.cabal
files. Then most cabal tools use cabal as a library to read/write the file, which necessarily expands common stanzas.
However, https://github.com/phadej/cabal-fmt/issues/20 says
cabal format
inlines common stanzas butcabal-fmt
doen't
so perhaps cabal-fmt
is a rare tool that doesn't rely on cabal library. (This also taught me that cabal
has its own inbuilt formatter!)
See also https://github.com/sdiehl/cabal-edit#limitations which mentions this issue. Upstream info: https://github.com/haskell/cabal/issues?q=label%3Aexact-print+ https://github.com/haskell/cabal/projects/9
Yeah, I also recently discovered that cabal format
is a thing. Should we just switch to that? I really don't care at all about Cabal formatting details, so long as it's consistent, and it seems like a good idea in general minimize the number of tools we're using.
I really don't care at all about Cabal formatting details
I don't much, but cabal format
does do a few things that make editing unnecessarily difficult: removing line breaks in default-extensions
(and not sorting them), not adding a trailing comma in build-depends
...
Then again, maybe I should just get in the habit of using cabal-edit
, then I really wouldn't care.
PS. we're getting very off-topic
Superceded by #140.
Right now, hackworthltd/vonnegut#765 is failing because of some HLint warnings about unused extension pragmas. I think these can be useful for some extensions that you really don't want to enable globally (
CPP
,TemplateHaskell
, maybeUndecidableInstances
...), so I wouldn't want to disable them, but for others it's just busywork.It's particularly annoying as they're not reported by HLS for some reason (https://github.com/haskell/haskell-language-server/issues/2042). Otherwise I would have caught the issue before committing.
Anyway, shall we just expand the
default-extensions
list in our cabal files? Currently we have the following enabled via pragmas, and I don't see any harm in enabling them everywhere:One annoying thing is that we currently have five identical
default-extensions
lists, for our various components. We could usecommon
stanzas in the cabal files to bring this down to three, but it's still less than ideal. (Roll onGHC2021
...)