cabal init generates badly formatted file

Created on 31 Aug 2018 · 8Comments · Source: haskell/cabal

(tried with cabal installed from master branch)

cabal init generates .cabal file with very long lines for fields like other-extensions, exposed-modules and build-depends. Fixing this by hand is tedious. Cabal format helps, but that's hard to discover (#2460). Ideally I think cabal should format the file before automatically.

cminit enhancement

Source

osa1

Most helpful comment

Just to clarify, this is what cabal init generates:

build-depends:       base >=4.11 && <4.12, QuickCheck >=2.11 && <2.12, hashable >=1.2 && <1.3, containers >=0.5 && <0.6, fingertree >=0.1 && <0.2, stm >=2.4 && <2.5, random >=1.1 && <1.2, text >=1.2 && <1.3, bytestring >=0.10 && <0.11, async >=2.2 && <2.3, transformers >=0.5 && <0.6, directory >=1.3 && <1.4, filepath >=1.4 && <1.5, free >=5.1 && <5.2

This is unusable without formatting first. Compare with cabal format output:

    build-depends:
        base >=4.11 && <4.12,
        QuickCheck >=2.11 && <2.12,
        hashable >=1.2 && <1.3,
        containers >=0.5 && <0.6,
        fingertree >=0.1 && <0.2,
        stm >=2.4 && <2.5,
        random >=1.1 && <1.2,
        text >=1.2 && <1.3,
        bytestring >=0.10 && <0.11,
        async >=2.2 && <2.3,
        transformers >=0.5 && <0.6,
        directory >=1.3 && <1.4,
        filepath >=1.4 && <1.5,
        free >=5.1 && <5.2

osa1 on 1 Sep 2018

👍3

All 8 comments

/cc @byorgey

23Skidoo on 31 Aug 2018

I personally prefer formatting of cabal init command so I wouldn't call it a badly formatted file. And in all my projects I format .cabal files in the style of cabal init (with alignment). I never heard of cabal format command before but after I tried this command now I see that there's no benefit in the cabal format formatting for me and I don't like the style of cabal format. So I'm voting for leaving cabal init formatting as it is.

chshersh on 1 Sep 2018

Just to clarify, this is what cabal init generates:

build-depends:       base >=4.11 && <4.12, QuickCheck >=2.11 && <2.12, hashable >=1.2 && <1.3, containers >=0.5 && <0.6, fingertree >=0.1 && <0.2, stm >=2.4 && <2.5, random >=1.1 && <1.2, text >=1.2 && <1.3, bytestring >=0.10 && <0.11, async >=2.2 && <2.3, transformers >=0.5 && <0.6, directory >=1.3 && <1.4, filepath >=1.4 && <1.5, free >=5.1 && <5.2

This is unusable without formatting first. Compare with cabal format output:

    build-depends:
        base >=4.11 && <4.12,
        QuickCheck >=2.11 && <2.12,
        hashable >=1.2 && <1.3,
        containers >=0.5 && <0.6,
        fingertree >=0.1 && <0.2,
        stm >=2.4 && <2.5,
        random >=1.1 && <1.2,
        text >=1.2 && <1.3,
        bytestring >=0.10 && <0.11,
        async >=2.2 && <2.3,
        transformers >=0.5 && <0.6,
        directory >=1.3 && <1.4,
        filepath >=1.4 && <1.5,
        free >=5.1 && <5.2

osa1 on 1 Sep 2018

👍3

@osa1 My bad, I haven't understand your ticket good enough. Yeah, I don't like long lists with dependencies as well.

chshersh on 2 Sep 2018

The format command simply calls readGenericPackageDescription followed by writeGenericPackageDescription. I don't think those existed when I first wrote cabal init. Right now, cabal init does its own pretty-printing; I think the correct solution would be to instead create a GenericPackageDescription and then call writeGenericPackageDescription, so it uses the same code path as cabal format.

byorgey on 3 Feb 2019

Hmm, actually, how do read/writeGenericPackageDescription deal with comments? As far as I can see the answer seems to be "they don't", which seems problematic from the point of view of cabal init...

byorgey on 3 Feb 2019

Correct, we don't have exactprint yet.

23Skidoo on 5 Feb 2019

One could extend https://github.com/haskell/cabal/blob/master/Cabal/Distribution/Fields/Pretty.hs with annotations, it's how I did in https://github.com/phadej/cabal-fmt/blob/master/src/CabalFmt/PrettyField.hs to add comments.