From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 64AC8BC69 for ; Wed, 26 Sep 2007 14:22:16 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAD3q+UbAXQImk2dsb2JhbACOMAEBAQEHCgcg X-IronPort-AV: E=Sophos;i="4.20,301,1186351200"; d="scan'208";a="16810387" Received: from discorde.inria.fr ([192.93.2.38]) by mail4-smtp-sop.national.inria.fr with ESMTP; 26 Sep 2007 14:22:16 +0200 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l8QCMBv9012895 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Wed, 26 Sep 2007 14:22:15 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAD3q+UbDuhNAnmdsb2JhbACOMAEBAQEHBAYFChg X-IronPort-AV: E=Sophos;i="4.20,301,1186351200"; d="scan'208";a="1508597" Received: from mail18.bluewin.ch ([195.186.19.64]) by mail1-smtp-roc.national.inria.fr with ESMTP; 26 Sep 2007 14:22:14 +0200 Received: from [192.168.1.58] (85.2.36.8) by mail18.bluewin.ch (Bluewin 7.3.121) id 46F3844F00103ACA; Wed, 26 Sep 2007 12:22:15 +0000 In-Reply-To: References: <46F95938.7030107@cs.umd.edu> <17487E59-04F2-4509-87B5-24377B051E9E@epfl.ch> <46F961E5.5060302@cs.umd.edu> <55A4E82E-3D05-4F79-A8A6-A87905EB4FC8@epfl.ch> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <45E37235-E843-4A27-95FF-88C41E5A3DCC@epfl.ch> Cc: caml-list@inria.fr Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Subject: Re: [Caml-list] Re: Cherry-picking modules (was Re: [ANN] OCaml Reins 0.1 - Persistent Data Structure Library) Date: Wed, 26 Sep 2007 14:22:19 +0200 To: Sylvain Le Gall X-Mailer: Apple Mail (2.752.2) X-Miltered: at discorde with ID 46FA4EF3.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bunzli:01 buenzli:01 ocaml:01 bug:01 bug:01 recompiled:01 invariants:01 pointers:01 ocaml:01 dependencies:01 orphaned:01 26,:98 drift:98 shun:98 maintainers:01 Le 26 sept. 07 =E0 12:26, Sylvain Le Gall a =E9crit : > ** you make a bug correction in libA, as many developers you don't =20 > have > time to submit bug upstream -> libA upstream and libA embedded =20 > begin to > be different I agree this is a problem. But realisticaly if you only bug fix, =20 interfaces usually do not change. Hence upstream and local don't =20 really drift away. You should be able to take a new version of libA =20 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 =20 relying on. If progB wants to use the new library it should be an =20 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 =20 centralized. Actually what I want is a little godi that I manage =20 myself for each of my projects. Let's be clear I actually also think =20 that direct source integration is not the best idea, but currently it =20= is what makes my life the simplest. I wouldn't mind not *directly* =20 integrate the sources but instead pointers to module downloads if =20 that allows me to easely regenerate/upgrade the modules. In some sense I want my projects to be -- modulo automatic downloads =20 of modules -- without free variables, self-contained, they should be =20 self-describing. The only untold prerequisite should be the ocaml dev =20= tools (and even...). The rest should be taken care of automatically. =20 I think that a tandem ocamlbuild/caml-get could go much more in that =20 direction, especially because, compared to godi, it would make the =20 system much more distributed. > Off course, as long as you will think that you must embed =20 > everything, you > won't need to learn godi (which is very simple) and you won't =20 > evolve on > this point. Well I used at some point. But for some reason -- I don't remember =20 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 =20= make libraries smaller and push them toward atomic modules: they =20 reveal the real dependencies, they are easier to maintain and it may =20 be easier to find new maintainers for orphaned modules. A developer =20 may find it an achievable task to maintain a single module he is =20 interested in but may shun in front of a cathedral-like library. Best, Daniel=