From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pBANSfbF030710 for ; Sun, 11 Dec 2011 00:28:41 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtIAAODq407RVdW2kGdsb2JhbABDhQeic4J9CCIBAQEBCQkNBxQEIYFyAQEBAQIBEgIPBBkBGx0BAwELBgULDwImAgIiAREBBQEcBhMIDAcHh2aYKwqLHEiCa4QbPYhxAgUMgSiJI4EWBJBIhCmNcT2Deg X-IronPort-AV: E=Sophos;i="4.71,332,1320620400"; d="scan'208";a="134862883" Received: from mail-yx0-f182.google.com ([209.85.213.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 11 Dec 2011 00:28:35 +0100 Received: by yenl9 with SMTP id l9so4593384yen.27 for ; Sat, 10 Dec 2011 15:28:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=SdAkncIY+Giur/euLdAHTBkug9S22UkCcaj5gf5BUPI=; b=yB1yQsgFmzq6/SG4X6kpbvq453q17i93Lr1mtzuY/2jggbMn2hLgXNWjVoze6FkTq1 AWuxyvwlOUwUIIDVmF4B5GEiSeIvN0VSN2G1RbhTejpiggc1+JZ0M8TxpO6YfLsIfW90 A3wGTq+BF/+kB7z9by/uHFitOeEQInTmSQNo8= Received: by 10.236.150.134 with SMTP id z6mr19761258yhj.42.1323559714242; Sat, 10 Dec 2011 15:28:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.101.162.18 with HTTP; Sat, 10 Dec 2011 15:28:13 -0800 (PST) In-Reply-To: <4EE37070.4010702@inria.fr> References: <55531934-37A5-4CC5-AB67-20CE4CCE8269@googlemail.com> <4EE37070.4010702@inria.fr> From: Jesper Louis Andersen Date: Sun, 11 Dec 2011 00:28:13 +0100 Message-ID: To: Xavier Leroy Cc: caml-list@inria.fr Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id pBANSfbF030710 Subject: Re: [Caml-list] OCaml maintenance status / community fork (again) On Sat, Dec 10, 2011 at 15:45, Xavier Leroy wrote: > 2- As pointed out already in this discussion, it's not on the Caml compiler > that community efforts are most needed.  For example, the most impactful > action that his community could take, in my opinion, is to adopt and embrace > a common packaging system like Cabal for Haskell. This one piqued my interest somewhat. I should refrain from commenting, but I can't help myself. What makes the Cabal infrastructure successful is that it is three different types of systems in one. First, there is hackage which provides a package repository of "blessed" packages - online search of the repository and general dumping ground of rotting packages. In other words, a perl CPAN for Haskell. Quality varies a lot, but at least there is a go-to place when searching for packages. Second, Cabal provides a system for automatically building packages. That is, if you have cabal, chances are that you can just blindly ask it to build the source code and you are done.... when it works. Thirdly, Cabal provides dependency tracking among packages. That is, given a package, you can easily fetch its dependencies and build another version of the package yourself. That said, my personal opinion, which probably not means much as I don't currently write scores of Ocaml or Haskell source, is still that Cabal is somewhat overengineered. Usually you end up with trouble when you try to build new packages. If you forget profiling flags, you have to rebuild essentially everything. Multiple versions of packages creates headaches when trying to use them (think the diamond-problem in a subtyping setting with multiple inheritance or functors without sharing constraints). And when I build Haskell source, I usually end up cursing the hell out of Cabal :) Erlang has a tool, doing parts two and three above: rebar. This tool is fundamentally simpler than Cabal. Its dependency tracking is essentially download instructions from software repositories and that's it. Packaging is done by creating the equivalent of static binaries .. dependencies are shoved into a release of an erlang runtime with all the necessary modules ready into a selfhosting, selfcontaining system. The approach is *much* simpler, but it works tremendously well. Even if it doesn't handle the problem of the diamond. It also allows different software to use different versions of libraries, but it doesn't really solve dependency convergence (that is yet another name for the diamond problem: A needs B and A needs C - but B needs D in version 1 and C needs D in version 2): digraph { D -> B -> A; D -> C -> A } In my experience, it is the simple solutions that works best, even if they can't handle certain scenarios. In some sense a certain amount of limitation is more a virtue than a curse. I'd also suggest splitting the search and indexing part from the dependency tracking and building part. They are far enough apart that they can be solved each by themselves. Finally there are two other things I would recommend one investigates: FreeBSD ports or Mac OSX homebrew for the indexing part. And pythons virtualenv (Ian Bicking was the original author). Virtualenv allows you to build a "virtual environment" in which you install python packages, which are distinct from the system installation. Of course you can symlink system libraries into the virtual environment, but it also means that programs can live next to each other and the sandboxing going on solves a lot of dependency problems in a simple way. In other words, to solve this, I'd much rather try to rig the excellent Ocamlbuild and Ocamlfind infrastructure such that it incorporates some of the above things, ... that is if it doesn't do that already... -- J.