Haskell library infrastructure coordinator

[Isaac Jones]

Peter Simons <simons@cryp.to> writes:

> Isaac Jones writes:
> (snip)
>  > Whenever people mention altering or shipping something with the
>  > compilers, red flags go up in my brain.
> 
> I didn't mean to emphasize this fact, sorry.

:)

> One idea would be to define an XML DTD for describing packages. Maybe
> work has even been done towards that end already. A conforming
> document could contain:
> (snip)

I added those comments to the LibraryInfrastructureNotes page for
now.  They sound good.

>  > - Packagers for various OSs have a sane way to create packages.
> 
> Building binary packages is a whole new world in terms of complexity,
> and it is a quality assurance nightmare.
> 
> Also, for _any_ binary package to be useful, it must be integrated
> with the packet manager of your Linux/FreeBSD/Apple OS X system. We
> could provide RPMs for starters, but that's only a fraction of the
> "market".

Right, I'm not suggesting that we centralize these packages.

> IMHO binary packages should be left to the distributors; the Haskell
> community should rather provide source code.

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].  To me, this is a
killer feature.  Proposals for a library infrastructure should deal
with the issue of integrating with packaging systems so as not to
duplicate work or infrastructure, and so we don't make it harder than
it has to be for those packagers.  More points if you can make it
easier for them.

>  > And more optionally:
>  > - A central repository of useful Haskell libraries can be maintained
>  > in a way that blends the best of cathedral & bazaar.
> 
> Well, I have to admit: For me, the whole process starts _here_. I
> think we should begin small and let the system evolve.

So to be clear: What happens now (correct me if I'm wrong) is that a
consensus is reached on this list about how new libraries should fit
into the hierarchy.  Then the compiler groups each integrate the
packages into their distribution, and when the next release comes
around, the end users get the libraries.

How would your boost-like distribution system interact with different
compilers and their different ways of packaging libraries?  Isn't some
kind of common build infrastructure like the one I propose still
necessary so that they don't have to repackage it?

> Again, I refer to boost.org. The project is doing exactly what I
> proposed, and it has lifted the C++ language to another level. They
> have practically taken over the language and library development for
> the new C++ Standard there! So the idea can't be that bad after all.

Some people think that the library infrastructure should look just
like FreeBSD, I happen to think it should look more like Python's
distutils, someone else might think that Debian has the answer.  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.  Lets try to look at a lot of
different tools and find the best synthesis.

peace,

isaac



[1] ] One issue, for instance, is that a whole plethora of seperate
binary packages needs to be provided for various compilers and
compiler versions since most of them are not binary compatible (see
the previous discussions on packaging stuff for Debian).  I think we
could help automate the process of generating and maintaining a large
set of binary packages.