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=1.0 required=5.0 tests=AWL,SPF_FAIL autolearn=disabled version=3.1.3 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id E77CEBC69 for ; Tue, 15 Jan 2008 22:27:11 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAGu0jEfAXQImh2dsb2JhbACQCwEBAQgKKYEUmiU X-IronPort-AV: E=Sophos;i="4.24,289,1196636400"; d="scan'208";a="6703078" Received: from discorde.inria.fr ([192.93.2.38]) by mail1-smtp-roc.national.inria.fr with ESMTP; 15 Jan 2008 22:27:11 +0100 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 m0FLRBi0019260 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Tue, 15 Jan 2008 22:27:11 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAGu0jEdQW+UCh2dsb2JhbACQCwEBAQgKKYEUmiU X-IronPort-AV: E=Sophos;i="4.24,289,1196636400"; d="scan'208";a="6703077" Received: from main.gmane.org (HELO ciao.gmane.org) ([80.91.229.2]) by mail1-smtp-roc.national.inria.fr with ESMTP; 15 Jan 2008 22:27:10 +0100 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JEtJL-0002k1-Lz for caml-list@inria.fr; Tue, 15 Jan 2008 21:27:07 +0000 Received: from ks300734.kimsufi.com ([91.121.65.225]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Jan 2008 21:27:07 +0000 Received: from sylvain by ks300734.kimsufi.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 15 Jan 2008 21:27:07 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: caml-list@inria.fr From: Sylvain Le Gall Subject: Re: On module distribution Date: Tue, 15 Jan 2008 21:27:01 +0000 (UTC) Message-ID: References: <92920466-3BCE-4A9F-9742-3396B07006F7@erratique.ch> <886B7896-B0EA-417A-99A9-DCB791FF09C7@erratique.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ks300734.kimsufi.com User-Agent: slrn/0.9.8.1pl2 (Debian) Sender: news X-Miltered: at discorde with ID 478D252F.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; le-gall:01 buenzli:01 berke:01 durak:01 ocamlfind:01 ocamlfind:01 compilation:01 tarballs:01 tarball:01 cpan:01 ocaml:01 humps:01 cpan:01 dependencies:01 ocaml:01 On 15-01-2008, Bünzli Daniel wrote: > Le 15 janv. 08 à 14:38, Berke Durak a écrit : > >> I think we should rather add to Ocamlbuild a module for calling >> ocamlfind, parsing its output, etc. This way ocamlbuild plugins >> could easily call ocamlfind, be it for configuration or compilation. > > My problem with ocamlfind is that it takes too much control over me. > Also it doesn't help you with the tedious publishing aspect (which I > try to mitigate by using news feeds) and it won't help you with the > binary update problem. > > Le 15 janv. 08 à 16:07, Sylvain Le Gall a écrit : > >> Unfortunately, a decentralized system has also several drawbacks: > [...] > > Yes of course. But the point is that we already have a decentralized > system. All these tarballs that are referenced from the hump and not > part of godi. My aim is to be able to quickly install or publish such > decentralized bits. Currently these two tasks take too much time: > using them, because everyone does it its own way, publishing them, > because you have to devise your own way (make a readme, think about > how to structure the tarball how to manage releases, announce on the > mailing list, etc.). The idea is to simplify all this uninteresting > business to entice people to share their modules. Lowering the bar may > mean a decrease in quality but in the end good modules and reliable > publishers will be identified by the community. > > Also note that the proposal in itself doesn't prevent the development > of a more authoritative, centralized and stable source of packages. > I think one of the best way to manage the bazaar is to follow the track of some other major languages (let say Perl) that has implemented a standard way to publish project with a good naming scheme et al (let say CPAN). My point is that unfortunately managing the bazaar of OCaml require more standard procedure and knowledge foreach member of the community. You will never reach the 100% compliance for every bits of the humps. If you get something like 10% it will already be something great (i really think it). As in debian, you need to have some kind of required knowledge to begin publishing good project. You cannot speed up this step. BUT after having this standard common knowledge that leads to an uniform packaging, you will be able to perform the second task: using them quickly... FYI, i recommend you to browse a little bit about Perl/CPAN, this is a great work about a centralized module publishing system: http://pause.perl.org Extract, to show you what mean a required basic knowledge: [quote] Your duties, the basics, traps We trust that you have read the perlmodinstall, perlmodlib, perlmodstyle, and perlnewmod manpages and that you regularly check out uploads to CPAN and that you have been watching CPAN activities for a while to have an impression of how things fit together. It usually boils down to (slogan shamelessly stolen and adapted from sudo(1)): 1. Think, better even talk before you upload 2. Respect the namespace of others [/quote] In particular perlmodstyle, perlmodlid and perlmodinstall are really a good way to understand years of publishing... >>> 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 >>> 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 > are developing an ocaml library with dependencies in that case your > project may become a package. If you are making an end-user > application this should not be used as a distribution mechanism, I > explicitly say that in the proposal, it is a tool for ocaml > _developers_. But still from a developer perspective it is a good > thing to have a mechanical way to track the external dependencies of > your project whether this is an end-user application or not, hence > packages should be (conceptually) managed per project. > OK, sorry i don't have understand what you have written. Regards, Sylvain Le Gall