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.9 required=5.0 tests=AWL,SPF_NEUTRAL autolearn=disabled version=3.1.3 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 8E3B9BC69 for ; Tue, 15 Jan 2008 21:41:41 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAGepjEdA6ba7nmdsb2JhbACQCwEBAQEHAggplBSHKA X-IronPort-AV: E=Sophos;i="4.24,288,1196636400"; d="scan'208";a="21277879" Received: from nf-out-0910.google.com ([64.233.182.187]) by mail4-smtp-sop.national.inria.fr with ESMTP; 15 Jan 2008 21:41:41 +0100 Received: by nf-out-0910.google.com with SMTP id e27so255634nfd.13 for ; Tue, 15 Jan 2008 12:41:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; bh=yt5XQu3dc9rOZMIA9E6zt6BbzqL7sNSYz8G4QpZ71ck=; b=SfO61lghsSdofvM6JRR5JVG2BJgNbOAQGY7Qhw3RvaNB7xpS1F/p21fMVRTRsdDOLwYGOwbfhXoK9k54KhyKE3XPHgrdfPCAxTi0NsUy1wtrxlmGxAQk25KHHHCBc+tulLmTH3li+P622j0lo8gmCKauiPQmy3qe54ghwq0cBXg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; b=QHcKtv16zVZrvCwhzswAWjWk5o1mbDEXFekDdJL1xG3i/L28SuDzwReydppNHn0P2haSQvpg9mbvfeMZSJl3Z6gfOg5EzTyFjnJJwiK7AgcQYg83XG7/9tpfmqAzSi0btxR+POX0yBH2YBiX7+NlF+7H+zzuI5sw+7Nd3Eiq3gs= Received: by 10.78.138.14 with SMTP id l14mr9709035hud.23.1200429700008; Tue, 15 Jan 2008 12:41:40 -0800 (PST) Received: from ?192.168.1.58? ( [85.2.9.207]) by mx.google.com with ESMTPS id 32sm14282753nfu.7.2008.01.15.12.41.39 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Jan 2008 12:41:39 -0800 (PST) Message-Id: <886B7896-B0EA-417A-99A9-DCB791FF09C7@erratique.ch> From: =?ISO-8859-1?Q?B=FCnzli_Daniel?= To: caml-list caml-list In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [Caml-list] Re: On module distribution Date: Tue, 15 Jan 2008 21:41:37 +0100 References: <92920466-3BCE-4A9F-9742-3396B07006F7@erratique.ch> X-Mailer: Apple Mail (2.915) Sender: =?ISO-8859-1?Q?Daniel=20B=FCnzli?= X-Spam: no; 0.00; bunzli:01 buenzli:01 berke:01 durak:01 ocamlfind:01 ocamlfind:01 compilation:01 tarballs:01 tarball:01 ocaml:01 dependencies:01 ocaml:01 stubs:01 dependencies:01 conceptually:01 Le 15 janv. 08 =E0 14:38, Berke Durak a =E9crit : > I think we should rather add to Ocamlbuild a module for calling =20 > ocamlfind, parsing its output, etc. This way ocamlbuild plugins =20 > could easily call ocamlfind, be it for configuration or compilation. My problem with ocamlfind is that it takes too much control over me. =20 Also it doesn't help you with the tedious publishing aspect (which I =20 try to mitigate by using news feeds) and it won't help you with the =20 binary update problem. Le 15 janv. 08 =E0 16:07, Sylvain Le Gall a =E9crit : > Unfortunately, a decentralized system has also several drawbacks: [...] Yes of course. But the point is that we already have a decentralized =20 system. All these tarballs that are referenced from the hump and not =20 part of godi. My aim is to be able to quickly install or publish such =20= decentralized bits. Currently these two tasks take too much time: =20 using them, because everyone does it its own way, publishing them, =20 because you have to devise your own way (make a readme, think about =20 how to structure the tarball how to manage releases, announce on the =20 mailing list, etc.). The idea is to simplify all this uninteresting =20 business to entice people to share their modules. Lowering the bar may =20= mean a decrease in quality but in the end good modules and reliable =20 publishers will be identified by the community. Also note that the proposal in itself doesn't prevent the development =20= of a more authoritative, centralized and stable source of packages. > In fact, Debian user reading this will see that i am having the same > sort of arguments that Debian has concerning the other distributions. > Debian has developped a very centric repository for all its packages > which other Linux distribution have not done. This tends to lead to =20= > have > more control on the QA of everything. Which is better to my mind. If the aim is to support an operating system I completly agree with =20 you. But the aim of my proposal is to support the ocaml development =20 bazaar which is not the same thing. >> 3. Manage packages per project (vs. per machine) to make project >> dependencies explicit. Thus a single command can install you the >> (OCaml + C stubs only) dependencies of your project on a fresh =20 >> system. >> If your project is a package itself, it facilitates its packaging . >> > > I don't agree project and package are not the same thing. You should > take into consideration that different distribution have different > packaging policy. That's not what I say. The _if_ of the last sentence is for when you =20 are developing an ocaml library with dependencies in that case your =20 project may become a package. If you are making an end-user =20 application this should not be used as a distribution mechanism, I =20 explicitly say that in the proposal, it is a tool for ocaml =20 _developers_. But still from a developer perspective it is a good =20 thing to have a mechanical way to track the external dependencies of =20 your project whether this is an end-user application or not, hence =20 packages should be (conceptually) managed per project. Best, Daniel=