Cabal (software)

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Cabal
Original author(s) Isaac Jones
Developer(s) Duncan Coutts
Initial release January 2005; 11 years ago (2005-01)
Stable release
1.24.0.0[1] / May 2016; 4 months ago (2016-05)
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.haskell.org/cabal/

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[edit]

Cabal has been introduced to simplify packaging of Haskell software and modules[citation needed]. 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[citation needed], which allow to escape the so-called Cabal hell (see below).

Cabalizing[edit]

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.[citation needed]

Use[edit]

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[edit]

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.[citation needed] 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[citation needed] and the tool stack,[9][10] which doesn't share its problems.

References[edit]

  1. ^ "Getting The Haskell Cabal". Retrieved 22 May 2016. 
  2. ^ "1.4. Release notes for version 6.4". GHC 6.4 user manual. Retrieved 2016-01-12. 
  3. ^ a b "cabal-install: The command-line interface for Cabal and Hackage.". Hackage. Retrieved 12 January 2016. 
  4. ^ "Cabal: A framework for packaging Haskell software". Hackage. Retrieved 12 January 2016. 
  5. ^ "Cabal/Survival - HaskellWiki". HaskellWiki. Retrieved 12 January 2016. 
  6. ^ "How we might abolish Cabal Hell". Well-Typed - The Haskell Consultants. Retrieved 12 January 2016. 
  7. ^ "[Haskell-cafe] ANN: Cabal v1.18.0 released". Haskell-cafe mailing list. Retrieved 12 January 2016. 
  8. ^ "Stackage Server". FP Complete. Retrieved 12 January 2016. 
  9. ^ "ANNOUNCING: first public beta of stack". FP Complete. Retrieved 12 January 2016. 
  10. ^ "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[edit]