Followups to libraries@haskell.org please. Greetings, After many rounds of email and discussion, some wiki work, and discussion at the HIM, I've finally put together a proposal for the Library Infrastructure Project. I've inserted the introduction below. The draft proposal itself is available in a variety of formats. I've also started a web page for the project under the haskell.org site: http://www.haskell.org/libraryInfrastructure/ Please let me know if there's anything that needs to be added, if anything is confusing, etc. Comments and questions are welcome by email or on the libraries@haskell.org mailing list. peace, isaac ps. I expect to be moving a lot of stuff off of the wiki page since it is duplicated here. ------------------------------------------------------------ Library Infrastructure Project Proposal 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. FULL TEXT AT: http://www.haskell.org/libraryInfrastructure/proposal/index.html
From the proposal:
The information would be held in a file, such as /etc/haskell/packages.conf[1] and ~/.haskell/packages.conf. [1] Is there any Unix system where etc is the wrong place for something like this? Yes, on some BSD systems (I think it was FreeBSD I was told about) I've heard that for software installed in /usr/local/bin, the config stuff should be in /usr/local/etc. -- David Roundy http://www.abridgegame.org
Great Work! A few questions: How will the Library Infrastructure itself be distributed? Will it be distributed separately? Or can it be included with Haskell implementations?
Is there any Unix system where etc is the wrong place for something like this?
For Mac OS X, I'd prefer to put it into Apple's standard directory for preferences files, which is /Library/Preferences. Putting it in /etc/ is slightly subotimal because it's only accessible via the command line, not via Apple's nice GUI. As long as there's nothing in the Setup.lhs scripts that depends on the exact path, everything is fine. Cheers, Wolfgang
Wolfgang Thaller
Great Work!
A few questions:
How will the Library Infrastructure itself be distributed? Will it be distributed separately? Or can it be included with Haskell implementations?
That is a good question because if there weren't an answer, it would imply a bootstrapping problem. Its actually answered under the "Use Cases" (section 5) for the Haskell Implementation [1] authors: "Include the Distribution module with the Haskell Implementations (in exchange, we can hopefully remove some libraries that are currently included with the Haskell Implementations)." I'm hoping that the Implementations (and their configuration settings) can be used as bootstrap configuration for the Distribution module (like where configuration files should go, in /etc or /Library/Preferences or whatever). So this brings up the question: won't certain things like haskell-config (section 4.4) need to be distributed with the implementations as well? Yes! And what if one implementation is installed already and you go to install another one? It'll probably have to try to find haskell-config, and if it can't, assume that its the only / first implementation being installed. If it finds haskell-config, then it'll probably want to ask haskell-config where to look for packages.conf. These issues are indeed a little thorny, but I think that if the implementations can configure haskell-config as a bootstrapping step in the configuration process, then they can use pretty generic code for querying haskell-config for the rest of the configuration questions related to packaging. peace, isaac [1] implementation == compiler or interpreter
In the proposal, you write: * The 3rd Party Author writes a Setup.lhs program. Setup.lhs imports elements from the Distribution module which does most of the hard work. A very common case, which should be our first priority, is a pure Haskell 98 module that needn't interface with any external systems. In this case the author only has to include the name of the program, the version, and the source files. He can then call Distribution.defaultMain to create an executable script with the proper command-line flags that knows how to interface with the Distribution.Package module. I'd prefer to have authors write data rather than a program, because programs can only be executed, but you can find other uses for data. Also programs are likely to include boilerplate that can get out of date more quickly.
Ross Paterson
I'd prefer to have authors write data rather than a program, because programs can only be executed, but you can find other uses for data.
Indeed, this is one of my arguments against using Make. There are several ways the author can do things, and I think that the Setup.lhs script offers the most flexibility. The information that the author needs to provide is basically the Package data type from section 4.3. We could have a file, lets call it setup.conf, which contains that information. The Setup.lhs script can parse setup.conf if it exists (there will be functions to do this in the distribution module), and so the Setup.lhs script would be basically:
import Distribution main = do pkg <- readSetup distUtilsMain pkg
There are two ways which you can offer access to the data for your "other uses": * distutilsMain (which should probably be called distributionMain) implements the 'info' command which will dump out the configuration information (see section 3.3) * Or other tools can parse the setup.conf file if they want the package information So I think that a setup.conf file would be very useful. I'll add this as a suggestion to the document. There is another possibility also. Each module could bind this package information to "moduleInfo", so that MyPackage.moduleInfo would give me the package information, and the setup script could import this. Then we'd have
import Distribution import MyPackage.Info -- or something main = distutilsMain MyPackage.moduleInfo
BUT I wouldn't want to have to parse the setup.conf file to get the info from MyPackage.moduleInfo since I don't want to do any IO, and I don't want to have _both_ setup.conf and MyPackage.moduleInfo since they're redundant. So my proposal would be to forget the setup.conf file, standardize on "moduleInfo" (or something) and if a non-haskell tool wants to get the package information directly from the package, it can use "Setup.lhs info". So we'd be parsing the output from stdout instead of a file, or we could add a -o flag to Setup.lhs to dump to a file that can be parsed by other tools. Arguments for including the executable program are that 1) it can do things that distutilsMain doesn't do. That is, it brings the full power of Haskell to the developer 2) it can wrap an entirely different build system (a make-based system for instance) and still offer the same interface as all of the tools that use distutilsMain. Neither of these is possible if we had _just_ setup.conf and distUtilsMain as an external program.
Also programs are likely to include boilerplate that can get out of date more quickly.
The boilerplate should be in distUtilsMain, which won't be included in the Setup script, but with the Distribution module. peace, isaac
participants (4)
-
David Roundy -
Isaac Jones -
Ross Paterson -
Wolfgang Thaller