Browse thread
[ANN] OCaml Reins 0.1 - Persistent Data Structure Library
[
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: | 2007-09-26 (12:22) |
From: | Daniel_Bünzli <daniel.buenzli@e...> |
Subject: | Re: [Caml-list] Re: Cherry-picking modules (was Re: [ANN] OCaml Reins 0.1 - Persistent Data Structure Library) |
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