Library Infrastructure Project

Isaac Jones

The Library Infrastructure Project is an effort to provide a framework for developers to more effectively contribute their software to the Haskell community.

The Haskell Implementations[1] come included with a good set of standard libraries, but this set is constantly growing and is maintained centrally. This model does not scale up well, and as Haskell grows in acceptance, the quality and quantity of available libraries is becoming a major issue. There are a wide variety of Haskell Implementations (both compilers and interpreters), each of which target a variety of hardware architectures and operating systems. There are also a number of different groups and individuals providing libraries, and these libraries depend upon each other and they depend upon external systems such as Java or GTK.

It can be very difficult for an end user to manage these dependencies and build all the necessary software at the correct version numbers on their platform: there is currently no generic build system to abstract away differences between Haskell Implementations and operating systems [2].

The Library Infrastructure Project seeks to provide some relief to this situation by building tools to assist developers, end users, and operating system distributers.

This is a draft proposal. If you have comments, please email Isaac Jones. The latest version of this document should be available in a variety of formats from the Library Infrastructure Project home page.

Table of Contents
1. High-Level Overview
2. Issues Facing Developers
2.1. Issues Facing Packagers
2.2. Why We Should Solve This
3. A Solution for Haskell in Haskell
3.1. The Module Design
3.2. But Why Should We Use Haskell?
3.3. Setup.lhs Command-Line Interface
3.4. An Example Setup.lhs Script
4. Distribution Module
4.1. Distribution.Build
4.2. Distribution.Install
4.3. Distribution.Package
4.3.1. PackageConfig Data Structure
4.4. haskell-config Command-line interface
4.5. haskell-pkg?
4.6. Distribution.Config
5. Use Cases
6. Means of Distribution and Layered Tools
7. Development Plan
A. Related Systems
A.1. Debian
A.2. Python Distutils
A.3. CPAN and Boost
A.4. FreeBSD's Ports System
A.5. The XEmacs Packaging System
A.6. Make-Based Systems
A.7. hmake

1. High-Level Overview

On a high level, we say that we want the system to help the user to install packages (whether they be libraries or applications) and their dependencies. To accomplish this, we propose a system similar to Python's Distutils (Section A.2) where each Haskell tool is distributed with a script (Section 3.4) which has a standard command-line interface. This script will provide a familiar user interface (Section 3.3) for compiling, installing, and removing packages and their dependencies.

For instance, to install the HUnit package, the user might download the source code from the web site, change into the HUnit directory, and type ./Setup.lhs install default, which would build and install the HUnit package for the default compiler. Similarly, he might type ./Setup.lhs install nhc to install the package for NHC.

Other tasks might be necessary to make the package known to the system, such as registering it with the Haskell Implementation of interest (Section 4.3). Such tasks would also be performed by this Setup program.



Herein, I will use Haskell Implementation as a catch-all phrase to include compilers and interpreters for the Haskell programming language.


Your humble author has in-depth knowledge of Debian GNU/Linux, but could probably learn a thing or two about other operating systems like Windows and MacOS. Should you notice anything here which offends your sense of operating system, please let me know.