Re: [Caml-list] Re: Cherry-picking modules (was Re: [ANN] OCaml Reins 0.1 - Persistent Data Structure Library)

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

Le 26 sept. 07 à 12:26, Sylvain Le Gall a écrit :

> ** you make a bug correction in libA, as many developers you don't  
> have
>   time to submit bug upstream -> libA upstream and libA embedded  
> begin to
>   be different

I agree this is a problem. But realisticaly if you only bug fix,  
interfaces usually do not change. Hence upstream and local don't  
really drift away.  You should be able to take a new version of libA  
and plug it right away.

> * libA is not embedded inside progB:
> ** libA do a minor bug correction -> progB just need to be recompiled
>    (no release), easy to do automatically with a dependency tracking

I disagree, the new version of libA may break invariants progB was  
relying on. If progB wants to use the new library it should be an  
explicit choice of progB's programmer.

> The only real needs is to have something that automatically
> download/build/install dependency! AND WE HAVE IT: godi!

The problem for me is that godi is both locally and remotly  
centralized. Actually what I want is a little godi that I manage  
myself for each of my projects. Let's be clear I actually also think  
that direct source integration is not the best idea, but currently it  
is what makes my life the simplest.  I wouldn't mind not *directly*  
integrate the sources but instead pointers to module downloads if  
that allows me to easely regenerate/upgrade the modules.

In some sense I want my projects to be -- modulo automatic downloads  
of modules -- without free variables, self-contained, they should be  
self-describing. The only untold prerequisite should be the ocaml dev  
tools (and even...). The rest should be taken care of automatically.  
I think that a tandem ocamlbuild/caml-get could go much more in that  
direction, especially because, compared to godi, it would make the  
system much more distributed.

> Off course, as long as you will think that you must embed  
> everything, you
> won't need to learn godi (which is very simple) and you won't  
> evolve on
> this point.

Well I used at some point. But for some reason -- I don't remember  
exactly -- it was getting too much in my way and I stopped using it.

Anyway even if you use godi I think that there are many advantages to  
make libraries smaller and push them toward atomic modules: they  
reveal the real dependencies, they are easier to maintain and it may  
be easier to find new maintainers for orphaned modules. A developer  
may find it an achievable task to maintain a single module he is  
interested in but may shun in front of a cathedral-like library.

Best,

Daniel