Toward a Unified Packaging System

[Simon Peyton-Jones]

| What would Haskell Implementations need to do to conform (at minimum):
|=20
| 1) Include Distribution.Package with your libraries
|=20
| 2) Add the packages marked "auto" to the search-path for imports
|=20
| 3) Allow a -package flag to add non-auto packages to the search-path
|=20
|=20
| So my question to you is, would the authors of the Haskell
| implementations add something like this to their systems, and help to
| port the Distribution.Package library?  Are there major things I'm
| missing, or is there anything here which would make this overly hard
| for any particular implementation?

As you know, I'm dead keen to see this happen.   Thank you for leading
this effort.

What would really help me is a summary, in one place (on the web) of
what you propose, without assuming much prior knowledge.  Rather than
specifying the interface of Distribution.Package, I suggest starting
with the desired goal:

   The goal is to make it possible for someone to download a package,
   cd to the root directory of the package,
   and run Setup.hs --ghc to install the package for GHC,
   or Setup.hs --hugs to install the package for Hugs

(Maybe that's not right already.  Doubtless there are other options.)

>From that point, you can describe various ways in which Setup.hs might
do its work:

- Distribution.Package provides facilities that make it easy to
	write various Setup.hs's
- the package is described by a data structure of type Package,=20
	by convention put in PackageDesc.hs (alongside Setup.hs)
- what support is needed from the GHC/Hugs/Nhc etc to let=20
	Setup.hs do its work
- what Joe Programmer would need to do to build a package.

etc.=20


Top down makes it possible for someone like me to understand why the
interfaces in Disribution.Package look the way they do.

Simon