On module distribution

["Bünzli Daniel" <daniel.buenzli@erratique.ch>]

A few month ago, after a discussion on cherry-picking modules in the  
reins library I thought a little bit about devising a system to  
facilitate module sharing. A system to simplify the tedious and  
uninteresting actions needed to be able to use and publish modules. At  
that time I started a design document for it, but as is expected in  
such cases the effort didn't last long.

However since people will be meeting in Paris in a few week to discuss  
these things I thought there may be some ideas to take in this very  
rough and incomplete draft of a system that I will never implement. So  
FWIW here's a link [1] to this document. In summary the main ideas  
were :

1. A decentralized system, anyone who can publish on a web server can  
publish a package. A central authority is a bottleneck to publication.

2. Use atom feeds [2] as the distribution medium. Atom feeds contain  
all the semantic information (authors, contributors, entries, rights,  
link to enclosure, labels etc.) needed to represent a package and its  
versions with release notes. Shortly a package is a feed, a version is  
an entry with an enclosure link to an archive. The only extensions  
needed (Atom allows this via xml name spaces) are new link attributes  
to describe version dependencies. Packages as feeds allow to follow  
their evolution with a plain newsfeed reader (which would also  
facilitates the maintenance of repositories like the hump). To avoid  
angle brackets, package feeds are generated from a tagged plain text  
README file.

3. Manage packages per project (vs. per machine) to make project  
dependencies explicit. Thus a single command can install you the  
(OCaml + C stubs only) dependencies of your project on a fresh system.  
If your project is a package itself, it facilitates its packaging .

4. Rely on ocamlbuild to do the hard work. Grosso modo in the way  
described here [3], which may be unrealistic for big projects, but on  
unices ressource consumption could be mitigated by making hard links  
to a cache maintained per user or machine (inspired by ideas in this  
message [4]).

Best,

Daniel

[1] http://erratique.ch/writings/mod.pdf
[2] http://tools.ietf.org/html/rfc4287
[3] http://brion.inria.fr/gallium/index.php/Working_on_dependent_projects_with_ocamlbuild
[4] http://caml.inria.fr/pub/ml-archives/caml-list/2007/04/ea46e76c646854347ad02dc10862a6ee.fr.html