Haskell library infrastructure coordinator

[Peter Simons]

Isaac Jones writes:

 > Yes, the packages will be left to the distributors. However, I
 > think that the library infrastructure should be able to provide
 > some metadata and tools for assisting packagers [1].

I just realize we really _are_ approaching the problem from different
ends! :-)

For the sake of avoiding misunderstandings, which I believe we had,
let me re-state my approach in other words. I'll address (hopefully)
all points you made, even though I don't quote your text:

A Haskell module is the most re-usable software component I have ever
seen. It is virtually impossible to write something that is _not_
re-usable by someone else. The problem is, though, that many modules
are really small, and thus do not warrant the effort of "releasing"
them. Plus, not everybody has the infrastructure to do it.

So if we could provide a platform where it takes you five minutes to
put your source code into an, say, Unstable.YourName directory,
hopefully many people would do just that. And then the source code
would be _there_. It could be re-used by others -- whereas otherwise,
nobody would ever have seen it.

Now, if the module is interesting and people are sending you e-mail,
asking for features or saying they like it, you'll be writing a short
manual and clean-up the API before you know it. So in effect, the
Haskell community would have one more good library to re-use. And if
the library is nice, we can "publish" it in the Stable area and users
of our distribution would just have it on their hard disk.

This is already an incredibly useful service, even if it doesn't do
anything but distribute the sources -- no build system and nothing.

BUT, once you have two or three libraries in this repository, you
could go ahead and create a build system for them. The more code comes
flowing in, the more complex will your build system get, until some
day, when it can

 - build all the Stable libraries on virtually any platform and with
   virtually any compiler,

 - run automated regression tests and produce result reports,

 - generate all the library documentation (maybe based on Haddock) and
   install them, either as HTML, PDF, or man pages(!),

 - generate a sophisticated web site, on which all the contents of the
   archive can be browsed, searched, etc.,

 - create several different binary package formats and provide means
   for users to run the regression tests on them.

Assuming this system exists, then everybody can check his code into
the Unstable area and provide build information for the it. (And this
has to be _really_ simple.) So everybody else can just check-out parts
of the Unstable branch and integrate them seamlessly into the rest,
albeit in the Unstable namespace.

Or programmers can chose to re-use the build system for their own
projects, if they want to release their package themselves.


 > Isn't some kind of common build infrastructure [...] necessary so
 > that [different compilers] don't have to repackage it?

I doubt there is such a thing as a common build infrastructure on
which everybody could agree. Just look at the reality today: We have
BSD Make, GNU Make, Jam, Boost.Jam, Odin, Cook, Automake and only god
knows what else -- all being actively used for all kinds of projects.
Even within the Haskell community, not everybody is using the fptools,
even though it clearly can build pretty much everything.

In my opinion, the reason for this lies in the nature of the task, not
in the lack of a better system. Given this, I don't have a problem
with the fact that people will use a different build infrastructure
than the one I designed.


 >> Again, I refer to boost.org.

 > [...] I'm rather convinced that duplicating any one system will
 > leave us with 1) the flaws of that system and 2) the flaws that
 > Haskell adds to the system by not being a perfect fit.

Uh, I was referring to Boost's model of running the source repository
and their success with it -- not to their build infrastructure.

Which, by the way, is entirely inappropriate for Haskell, unless we're
interested in several hundred kilobytes worth of C++-compiler
properties. :-)

Peter