Cabal (software)
Original author(s) | Isaac Potoczny-Jones |
---|---|
Developer(s) | Duncan Coutts |
Initial release | January 2005 |
Stable release |
1.24.0.0[1]
/ May 2016 |
Development status | Active |
Written in | Haskell |
Operating system | Any Unix-like, Microsoft Windows |
Size | 0.4 megabytes |
Available in | English |
Type | Application level package manager |
License | BSD |
Website |
www |
The Haskell Cabal is the Common Architecture for Building Applications and Libraries; it aids in the packaging and distribution of software packages. It is contained in the Haskell Platform.
History
Cabal has been introduced to simplify packaging of Haskell software and modules. It was added to the Glasgow Haskell Compiler version 6.4 as default package manager,[2] along GHC's internal manager ghc-pkg. The actual binary cabal[3] and the library Cabal[4] are developed in different packages.
Throughout its development it has gained additional features, such as sandboxes, which allow to escape the so-called Cabal hell (see below).
Cabalizing
Cabalizing is the process of making a library written in the Haskell programming language conformant to the requirements of the Cabal library infrastructure. Cabalizing may be required if a library was initially developed without taking those requirements into consideration, or if it was developed prior to the introduction of Cabal to the Haskell community.
Use
Cabal packages provide a standard set of metadata and build process; thus, it is possible to develop tools to upload Cabal packages to the CPAN-like community repository of software, Hackage, or even allow for automated downloading, compilation, and installation of desired packages from Hackage.[3]
Criticism
Since Cabal uses a global package repository by default, version conflicts in dependencies can lead to Cabal hell, a state where certain packages cannot get installed without re-installing already existing ones and therefore breaking the other packages.[5][6]
Although version 1.18 introduced sandboxes and improved this dependency hell,[7] non-proper use of sandboxes could still lead to problems, since packages on Hackage might not build or version boundaries on dependencies were too loose. As a result, a more stable (but less bleeding edge) variant of Hackage called Stackage has been created by FP Complete. [8] It was later extended with Haskell LTS and the tool stack,[9][10] which doesn't share its problems.
References
- ↑ "Getting The Haskell Cabal". Retrieved 22 May 2016.
- ↑ "1.4. Release notes for version 6.4". GHC 6.4 user manual. Retrieved 2016-01-12.
- 1 2 "cabal-install: The command-line interface for Cabal and Hackage.". Hackage. Retrieved 12 January 2016.
- ↑ "Cabal: A framework for packaging Haskell software". Hackage. Retrieved 12 January 2016.
- ↑ "Cabal/Survival - HaskellWiki". HaskellWiki. Retrieved 12 January 2016.
- ↑ "How we might abolish Cabal Hell". Well-Typed - The Haskell Consultants. Retrieved 12 January 2016.
- ↑ "[Haskell-cafe] ANN: Cabal v1.18.0 released". Haskell-cafe mailing list. Retrieved 12 January 2016.
- ↑ "Stackage Server". FP Complete. Retrieved 12 January 2016.
- ↑ "ANNOUNCING: first public beta of stack". FP Complete. Retrieved 12 January 2016.
- ↑ "What do Haskellers want? Over a thousand tell us".
Package management with cabal is the single worst aspect of using Haskell. Asked if improvements to package management would make a difference to their future choice of Haskell for a project, 38% said it would be "crucial" and a further 29% said it would be "important". Comments connected cabal with words like hell, pain, awful, sucks, frustrating, and hideous. Only this topic showed such grave dissatisfaction.
External links
Wikibooks has a book on the topic of: Haskell/Packaging |
- Official website
- "The Haskell Cabal: A Common Architecture for Building Applications and Tools" -(the original proposal and specification, by Isaac Jones, Simon Peyton Jones, Simon Marlow, Malcolm Wallace, and Ross Patterson; a version was submitted to the Haskell Workshop, 2005)
- Cabal talk -(slides)