Open gbaz opened 6 years ago
Like all similar features, I think this requires comment-preserving exactprint to be implemented first.
Hrm. Ok, so in #2460 we have a full correct data roundtrip almost there except for one encoding issue. However, I guess that still leaves comments out. I confess I don't still know the full state of things. Are we fully on the parsec parsers now? Are there plans for a comment-preserving exactprint or any tickets describing the issue more fully. Or is there just a desire for this?
(i guess related prior art is ghc-exactprint and also https://dorchard.wordpress.com/2017/09/20/scrap-your-reprinter/)
Are we fully on the parsec parsers now?
For .cabal files, yes; since cabal 2.2
for cabal.project / cabal.config not yet
Are there plans for a comment-preserving exactprint
Yes, definitely -- the ability to roundtrip .cabal files is essential to achieve some goals for hackage revisions! But as usual, it's a priority-scheduling / scarce resource issue... in hindsight, this could have been a great GSOC project...
/cc @phadej
In the meantime, cabal-fmt
can also update the module list. See here for how to use it: http://oleg.fi/gists/posts/2019-08-11-cabal-fmt.html#extra-expand-exposed-modules-and-other-modules
The syntax is open to bikeshedding, but the idea is that
cabal init
auto-populates modules in a cabal file when it creates it. However, there's no way to auto-populate additional modules you may have since added.It would be nice if we could add an
update
command that added to other-modules all modules in the source-dir not otherwise listed, so people didn't have to add them by hand as they added new modules to a project. We could even have a flag that controlled if they were added to exposed or other in the case of library stanzas.Adding this as a subcommand of format makes sense imho because it uses the same round-tripping as format, and it also is blocked on public exposure by the same round-trip issues listed in : https://github.com/haskell/cabal/issues/2460