The cabal-bounds package
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
You have to ensure, that the Cabal library of cabal-bounds matches the one used by the cabal binary:
$> cabal --version cabal-install version 188.8.131.52 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.
You can restrict the modification to certain sections in the cabal file by specifing the type and the name of the section:
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:
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.
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
[Skip to Readme]
|Versions||0.1.2, 0.1.3, 0.1.4, 0.1.5, 0.1.6, 0.1.7, 0.1.8, 0.1.9, 0.1.10, 0.1.11, 0.1.12, 0.1.13, 0.1.14, 0.1.15, 0.1.16, 0.2, 0.2.1, 0.3, 0.4, 0.4.1, 0.5, 0.6, 0.7, 0.8, 0.8.1, 0.8.2, 0.8.3, 0.8.4, 0.8.5, 0.8.6, 0.8.7, 0.8.8, 0.8.9, 0.9, 0.9.1, 0.9.2, 0.9.3, 0.9.4, 0.9.5, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4, 1.0.5, 1.1.0 (info)|
|Dependencies||base (>=3 && <5), Cabal (>=1.18.0 && <1.19), cmdargs (>=0.10.5 && <0.11), lens (>=4.0.1 && <4.1), strict (>=0.3.2 && <0.4) [details]|
|Source repository||head: git clone https://github.com/dan-t/cabal-bounds|
|Uploaded||Thu Feb 27 11:28:40 UTC 2014 by DanielTrstenjak|
|Downloads||7721 total (67 in the last 30 days)|
|Status||Docs available [build log]
Successful builds reported [all 1 reports]
For package maintainers and hackage trustees