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 (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 <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 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.. Regards, Sylvain Le Gall