Cabal (software)

Cabal
Original author(s) Isaac Potoczny-Jones
Developer(s) Duncan Coutts
Initial release January 2005 (2005-01)
Stable release
1.24.0.0[1] / May 2016 (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

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

  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. 1 2 "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

Wikibooks has a book on the topic of: Haskell/Packaging


This article is issued from Wikipedia - version of the 10/10/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.