Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[ANN] OCaml Reins 0.1 - Persistent Data Structure Library
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-09-26 (10:37)
From: Sylvain Le Gall <sylvain@l...>
Subject: Re: Cherry-picking modules (was Re: [ANN] OCaml Reins 0.1 - Persistent Data Structure Library)
On 26-09-2007, Daniel Bünzli <> wrote:
> Le 26 sept. 07 à 01:33, Sylvain Le Gall a écrit :
>> Anyway, embeding any external code into your project is a nightmare  
>> for
>> security/maintenance in the long term... I would avoid this  
>> solution if
>> i want things that doesn't have problem.
> As I explained I don't think so. In the best case you delegate the  
> nightmare to the user. Can you explain exactly where the nightmare is  
> with embedding ? If the distributed modules you integrate are  
> labelled with a version, I don't see it. The work needed for  
> maintenance in the long term is exactly the same, except only the  
> developer has to care. As for security updates in ocaml, you cannot  
> anyway rely on dynamic linking. Which I see as a good thing, for  
> applications dynamic linking creates more problems than it solves and  
> should be avoided most of the time (except of course for system  
> libraries).

OK, let me make myself clear, about the fact that embedding things is
the worst case. Let consider library libA and program progB, progB
requires libA:
* libA is embedded inside progB:
** libA do a minor bug correction -> you need to re-release progB even if
  nothing has changed inside it 
** 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
* 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
** you make a bug correction in libA -> you have no choice than to
   report it to upstream libA, because your bug correction will disappear
   in next libA release

Unfortunately i have seen projects (like mldonkey) which has embedded a
lot of libraries. The result of this is that you only creates branches,
with no real feedback to upstream author. This is a shame, it
duplicates works of bug correction for libA upstream and progB.

It is funny, because when you see other big languages -- which are
working very well -- like Perl, they all try to avoid embedding libraries!

The only real needs is to have something that automatically
download/build/install dependency!

AND WE HAVE IT: godi! 

Or if you want things more distro based: debian...

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.

I really do invite you to try godi/ocamlfind? 

These tools are really great and are a solution for the kind of problems
you describe..

Sylvain Le Gall