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

[Sylvain Le Gall <sylvain@le-gall.net>]

On 26-09-2007, Sylvain Le Gall <sylvain@le-gall.net> wrote:
> On 26-09-2007, Daniel Bünzli <daniel.buenzli@epfl.ch> 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
>

Forget the best "worst case".

You ship libA -- with a local modification in libB. A developper want to
use libA (original -- no modification) and libB...

Is it possible ?

I think you will have a conflict between the two version (.cmi exists
with different signatures)...

So by shipping libA with modification, you cannot use libA into another
library...

Regards,
Sylvain Le Gall