Contrib packages

[Simon Peyton-Jones]

Dear library folk

Dominic has been writing a crypto library:

| I'm not clear what happens at the moment. I had naively assumed that
having
| created my library that it would be put into the ghc cvs repository
and
| would then be available in the same way other libraries are when you
install
| ghc.
|=20
| Do libraries get put into the ghc cvs repository?
| If they do, do they get put into the ghc release?
| If they don't then how does someone who wants to use one get hold of
it?

George wants Koen's Chunk library:

| > Take a look at:
| >
| > http://www.cs.chalmers.se/Cs/Grundutb/Kurser/afp/Lab2/Chunk.hs
| >
| > Is that what you want?
| Yes, that's much more like it.  Any chance of this module getting put
into
| the standard distribution?

These both raise a common question: how can someone distribute a
library?   (This is a different question to the library-infrastructure
question about how to build a library, which we've been discussing
recently.)

What Dominic and George would like is for their desired library to just
"come with GHC" (and Hugs, NHC).  But this model is unsustainable for us
(the GHC team), and I expect it is unsustainable for Hugs and NHC.  It's
just too much work to be responsible for all the libraries that anyone
might contribute.  Adding just one more module isn't a problem, but
iterating that process certainly is.  Simon and I are beginning to sink
--- partly a welcome side effect of GHC's widespread use --- so we need
to find=20
ways to get ourselves off the critical path for libraries, to avoid
impeding their
development.  (As I remarked in an earlier message, I think that ways to
make
libraries flourish is the top challenge facing the Haskell community.)


The main alternative to "packaged by the GHC/Hugs/NHC team" route is
this:
	the person writing the library makes it into a separate GHC
package (and
	something similar for Hugs, NHC), and distributes it separately

This is the model followed by Sven's GLUT package, for example.  GLUT is
physically kept in the GHC/Hugs CVS library repository, but Sven
maintains and distributes it. He can fix bugs, and distribute new
versions whenever he likes, independent of GHC releases.

This is quite a high-cost model, though.   It's a fair amount of work to
build binary distributions of libraries for different platforms and for
different Haskell implementations.  For example, I can't see Koen doing
that just for his one-module Chunk library; and Dominic might find it a
bit daunting for his crypto libraries too. =20

What we want, I think, is an aggregation mechanism.  In particular

	there could be one or more "contrib" packages,=20
	optionally hosted at fptools/libraries,
	containing code contributed and maintained by different folk,
	but packaged and distributed by one person, a Contrib Builder
		(better titles welcome)

Note that

a) A Contrib Builder may, but does not have to, use the library
infrastructure
we are discussing in another thread.  But s/he will need to provide some

infrastructure so that people contributing libraries can build and test
their
library.  The Contrib Builder will probably want to do automated nightly

build/test runs of the package.

b) A given package (=3D group of library modules, distributed as a =
single
bundle)
can have a Contrib Builder for GHC, another for Hugs and another for
NHC.  That's
the way the core libraries work right now: there's a single shared code
base in
fptools/libraries, and the GHC, Hugs and NHC teams each build
distributions from
that common code base.

When a new version of GHC/Hugs/NHC comes out, the appropriate Conrib
Builder(s)
should make a new version of their package for the new version of the
compiler,
if necessary.  But of course, the package can be released more
frequently than that.

c) There can be more than one contrib package.   A package is just a
unit of=20
distribution, to amortise the cost of building distributions for
multiple modules.
Ideally, a package would contain thematically related modules, but not
necessarily.

d) Every module in a package will occupy a slot in the common
hierarchical module
name space; so library authors should negotiate for their name, using
the libraries
mailing list, as they do now.



OK so that's the idea.

1.  Does it seem like a reasonable idea?

2.  There is a pressing need for the first Contrib Builder for libraries
	like Dominic's crypto and Koen's Chunk library.  Any volunteers?
	Even for one implementation target?

Simon