More diff friendly pretty printing of cabal files #1708

Merged
merged 3 commits into from Apr 8, 2014

Projects

None yet

3 participants

@dan-t
Contributor
dan-t commented Mar 1, 2014

Now the 'fieldGet' function of 'FieldDescr' does the
whole pretty printing of the field. Previously only the
values have been pretty printed by 'fieldGet' and the
name of the field with the colon have been printed
in the 'PrettyPrint' module.

But this separation made it more difficult to handle the
pretty printing of fields differently, because some fields
should be just printed in one lines and others - having several
values - should be printed nested with each value on a new line.

This difference in the printing of the fields is now handled by
the 'FieldDescr' constructor functions in 'ParseUtils'.

Now the 'listField' and 'commaListField' functions create 'FieldDescr'
that nest their values and all other functions create one line
for the whole field.

@dan-t dan-t More diff friendly pretty printing of cabal files
Now the 'fieldGet' function of 'FieldDescr' does the
whole pretty printing of the field. Previously only the
values have been pretty printed by 'fieldGet' and the
name of the field with the colon have been printed
in the 'PrettyPrint' module.

But this separation made it more difficult to handle the
pretty printing of fields differently, because some fields
should be just printed in one lines and others - having several
values - should be printed nested with each value on a new line.

This difference in the printing of the fields is now handled by
the 'FieldDescr' constructor functions in 'ParseUtils'.

Now the 'listField' and 'commaListField' functions create 'FieldDescr'
that nest their values and all other functions create one line
for the whole field.
73dd1c2
@dan-t
Contributor
dan-t commented Mar 1, 2014

A pretty printed cabal file now looks like:

name: cabal-bounds
version: 0.1.16
cabal-version: >=1.9.2
build-type: Simple
license: BSD3
license-file: LICENSE
maintainer: daniel.trstenjak@gmail.com
synopsis: A command line program for managing the bounds/versions of the dependencies in a cabal file.
description:
    'cabal-bounds' is able to do two things:
    .
    * drop the bounds of the dependencies in the cabal file
    .
    * update the bounds of the dependencies in the cabal file using the cabal build information
    .
    .
    .
    /Example: Raise the upper Bounds/
    .
    .
    If you have several cabalized projects, then it can be quite time consuming to keep the
    bounds of your dependencies up to date. Especially if you're following the package versioning
    policy, then you want to raise your upper bounds from time to time, to allow the building with
    newer versions of the dependencies.
    .
    'cabal-bounds' tries to automate this update process to some degree. So a typical update process might look like:
    .
    > # update the version infos of all libraries
    > $> cabal update
    >
    > # drops the upper bound of all dependencies in 'myproject.cabal',
    > # most likely you want to ignore 'base'
    > $> cabal-bounds drop --upper --ignore=base myproject.cabal
    >
    > # create a cabal sandbox for building of 'myproject'
    > $> cabal sandbox init
    >
    > # build 'myproject'
    > $> cabal install
    >
    > # update the upper bound of all dependencies in 'myproject.cabal'
    > # by the cabal build information
    > $> cabal-bounds update --upper --ignore=base myproject.cabal dist/dist-sandbox-*/setup-config
    .
    .
    .
    /Example: Bound Changes/
    .
    .
    The '=>' shows what the result is of the operation for every dependency. Left is the dependency before
    calling the command, right the one after calling.
    .
    > $> cabal-bounds drop myproject.cabal
    > lens >=4.0.1 && <4.1   =>   lens
    >
    > $> cabal-bounds drop --upper myproject.cabal
    > lens >=4.0.1 && <4.1   =>   lens >=4.0.1
    .
    If the cabal build (the setup-config) uses 'lens 4.1.2', then the results of the 'update' command would be:
    .
    > $> cabal-bounds update myproject.cabal setup-config
    > lens >=4.0.1 && <4.1   =>   lens >=4.1.2 && <4.2
    > lens                   =>   lens >=4.1.2 && <4.2
    >
    > $> cabal-bounds update --lower myproject.cabal setup-config
    > lens >=4.0.1 && <4.1   =>   lens >=4.1.2
    > lens <4.1              =>   lens >=4.1.2
    > lens                   =>   lens >=4.1.2
    >
    > $> cabal-bounds update --upper myproject.cabal setup-config
    > lens >=4.0.1 && <4.1   =>   lens >=4.0.1 && <4.2
    > lens >=4.0.1           =>   lens >=4.0.1 && <4.2
    > lens                   =>   lens >=4.1.2 && <4.2
    .
    .
    .
    /Installation/
    .
    .
    You have to ensure, that the 'Cabal' library of 'cabal-bounds' matches the one used by the 'cabal' binary:
    .
    > $> cabal --version
    > cabal-install version 1.18.0.2
    > using version 1.18.1 of the Cabal library
    >
    > $> cabal install --constraint="Cabal == 1.18.1" cabal-bounds
    .
    If you update the 'cabal' binary and the used 'Cabal' library changes, then you have to rebuild 'cabal-bounds'.
    .
    .
    .
    /Options/
    .
    .
    You can restrict the modification to certain sections in the cabal file by specifing the type and the name of the section:
    .
    * --library
    .
    * --executable=name
    .
    * --testsuite=name
    .
    * --benchmark=name
    .
    If you omit these options, then all sections are considered and modified.
    .
    .
    You can also restrict the modification of dependencies by specifing which dependencies should only or shouldn't be modified:
    .
    * --only=name
    .
    * --ignore=name
    .
    If you omit these options, then all dependencies are considered and modified.
    .
    .
    All options taking a name can be specified multiple times:
    .
    e.g. '--executable=exe1 --executable=exe2' or '--ignore=base --ignore=whatever'
    .
    Please consult 'cabal-bounds --help' for a complete list of options.
    .
    .
    .
    /Issues/
    .
    .
    Perhaps the currently most annoying thing is, that you have to live with the reformating of your
    'cabal' file done by the pretty printer of the 'Cabal' library.
    .
    To reformat your 'cabal' file without changing any bounds you can call 'cabal-bounds' with the name of
    a section that isn't present in the 'cabal' file:
    .
    > $> cabal-bounds drop --executable=blub myproject.cabal
category: Utils
author: Daniel Trstenjak
extra-source-files:
    README.md
    tests/inputFiles/original.cabal
    tests/inputFiles/setup-config
    tests/goldenFiles/*.cabal
    tests/outputFiles/.gitignore

source-repository head
    type: git
    location: https://github.com/dan-t/cabal-bounds

library
    build-depends:
        base >=3 && <5,
        cmdargs >=0.10.5 && <0.11,
        lens >=4.0.1 && <4.1,
        strict >=0.3.2 && <0.4,
        Cabal >=1.18.0 && <1.19
    exposed-modules:
        CabalBounds.Args
        CabalBounds.Main
    exposed: True
    buildable: True
    cpp-options: -DCABAL
    hs-source-dirs: src
    other-modules:
        Paths_cabal_bounds
        CabalBounds.Bound
        CabalBounds.Targets
        CabalBounds.Dependencies
        CabalBounds.Drop
        CabalBounds.Update
        CabalBounds.Lenses
    ghc-options: -W

executable cabal-bounds
    build-depends:
        base >=3 && <5,
        cmdargs >=0.10.5 && <0.11,
        lens >=4.0.1 && <4.1,
        strict >=0.3.2 && <0.4,
        Cabal >=1.18.0 && <1.19
    main-is: Main.hs
    buildable: True
    cpp-options: -DCABAL
    hs-source-dirs: src
    other-modules:
        Paths_cabal_bounds
        CabalBounds.Args
        CabalBounds.Bound
        CabalBounds.Targets
        CabalBounds.Dependencies
        CabalBounds.Drop
        CabalBounds.Update
        CabalBounds.Lenses
        CabalBounds.Main
    ghc-options: -W

test-suite cabal-bounds-tests
    build-depends:
        base >=3 && <5,
        cmdargs >=0.10.5 && <0.11,
        lens >=4.0.1 && <4.1,
        strict >=0.3.2 && <0.4,
        Cabal >=1.18.0 && <1.19,
        tasty ==0.7.*,
        tasty-golden >=2.2.0.2 && <2.3,
        filepath >=1.3.0.1 && <1.4,
        cabal-bounds -any
    type: exitcode-stdio-1.0
    main-is: tests/Main.hs
    buildable: True
    ghc-options: -W
@23Skidoo 23Skidoo and 1 other commented on an outdated diff Mar 9, 2014
.../Distribution/PackageDescription/PrettyPrintIndent.hs
@@ -0,0 +1,8 @@
+
+module Distribution.PackageDescription.PrettyPrintIndent
@23Skidoo
23Skidoo Mar 9, 2014 Member

I don't think we need a separate module just for a single constant. Can't this go under Distribution.ParseUtils?

@dan-t
dan-t Mar 9, 2014 Contributor

On Sun, Mar 09, 2014 at 01:21:22PM -0700, Mikhail Glushenkov wrote:

I don't think we need a separate module just for a single constant. Can't this
go under Distribution.ParseUtils?

Yes, it might be overkill, putting 'indentWith' into 'ParseUtils' should
be sufficient.

Greetings,
Daniel

@23Skidoo
Member
23Skidoo commented Mar 9, 2014

I think I fixed the Travis failure in a573d4b.

edit: Oops, I was thinking about #1699.

@23Skidoo
Member

@dan-t

I think we can merge this once you move that constant to Distribution.ParseUtils.

@dan-t
Contributor
dan-t commented Mar 21, 2014

On Fri, Mar 21, 2014 at 10:30:04AM -0700, Mikhail Glushenkov wrote:

I think we can merge this once you move that constant to
Distribution.ParseUtils.

Ok, done.

@tibbe
Member
tibbe commented Apr 7, 2014

I was going to merge this today but there are now merge conflicts (sorry!). Do you mind fixing those and then I'll merge?

@dan-t dan-t Merge remote-tracking branch 'cabal/master'
Conflicts:
	Cabal/Distribution/ParseUtils.hs
c13850d
@dan-t
Contributor
dan-t commented Apr 7, 2014

On Mon, Apr 07, 2014 at 09:17:20AM -0700, Johan Tibell wrote:

I was going to merge this today but there are now merge conflicts (sorry!). Do
you mind fixing those and then I'll merge?

Ok, should be done now.

Greetings,
Daniel

@tibbe tibbe merged commit c13850d into haskell:master Apr 8, 2014

1 check passed

continuous-integration/travis-ci The Travis CI build passed
Details
@dan-t
Contributor
dan-t commented Apr 8, 2014

On Mon, Apr 07, 2014 at 11:53:19PM -0700, Johan Tibell wrote:

Merged #1708.

I just saw, that the extension field is currently pretty printed:

default-extensions:
CPP

Normally there shouldn't be that much values for this field, so printing
it in one line might be more appropriate:

default-extensions: CPP

I could do this change if you would like it.

Greetings,
Daniel

@tibbe
Member
tibbe commented Apr 8, 2014

Please.

On Tue, Apr 8, 2014 at 11:12 AM, Daniel Trstenjak
notifications@github.comwrote:

On Mon, Apr 07, 2014 at 11:53:19PM -0700, Johan Tibell wrote:

Merged #1708.

I just saw, that the extension field is currently pretty printed:

default-extensions:
CPP

Normally there shouldn't be that much values for this field, so printing
it in one line might be more appropriate:

default-extensions: CPP

I could do this change if you would like it.

Greetings,
Daniel

Reply to this email directly or view it on GitHubhttps://github.com/haskell/cabal/pull/1708#issuecomment-39826972
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment