RE: Toward a Unified Packaging System

| What would Haskell Implementations need to do to conform (at minimum): | | 1) Include Distribution.Package with your libraries | | 2) Add the packages marked "auto" to the search-path for imports | | 3) Allow a -package flag to add non-auto packages to the search-path | | | 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, by convention put in PackageDesc.hs (alongside Setup.hs) - what support is needed from the GHC/Hugs/Nhc etc to let Setup.hs do its work - what Joe Programmer would need to do to build a package. etc. Top down makes it possible for someone like me to understand why the interfaces in Disribution.Package look the way they do. Simon
participants (1)
-
Simon Peyton-Jones