Browse thread
On module distribution
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Bünzli_Daniel <daniel.buenzli@e...> |
| Subject: | On module distribution |
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