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 pBBB3L6I012457 for ; Sun, 11 Dec 2011 12:03:21 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoACAJyN5E7U436rlGdsb2JhbABDhQeic4MEIgEBAQEJCwkJFAMigXIBAQQBIwRSBQsLGAICJgICVwYTFAeHbQKjVZBdgTSJI4EWBI0MgzyJdIxd X-IronPort-AV: E=Sophos;i="4.71,334,1320620400"; d="scan'208";a="134898908" Received: from moutng.kundenserver.de ([212.227.126.171]) by mail1-smtp-roc.national.inria.fr with ESMTP; 11 Dec 2011 12:02:59 +0100 Received: from office1.lan.sumadev.de (dslb-188-097-010-110.pools.arcor-ip.net [188.97.10.110]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MaU9p-1RKd8l21Dl-00K4mk; Sun, 11 Dec 2011 12:02:58 +0100 Received: from [192.168.178.11] (546BF816.cm-12-4d.dynamic.ziggo.nl [84.107.248.22]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 04792C00C7; Sun, 11 Dec 2011 12:02:57 +0100 (CET) From: Gerd Stolpmann To: Jesper Louis Andersen Cc: Xavier Leroy , caml-list@inria.fr In-Reply-To: References: <55531934-37A5-4CC5-AB67-20CE4CCE8269@googlemail.com> <4EE37070.4010702@inria.fr> Content-Type: text/plain; charset="UTF-8" Date: Sun, 11 Dec 2011 12:02:57 +0100 Message-ID: <1323601377.6079.40.camel@samsung> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:LEn7T1t41MQBvpX2MaSnzIDeP1YhSxS6OnfO4EcI3f8 AzZB5moECyud0r0I7joViOr02s53LynJzlrbFq468ZYp7T/TVh JrwSsJsZb87TDhnmiL3ztXc42JnbYOVzoWJ/esyHYCvOiaYiet SJ+CBF7Ld2HxNgPzm5NbjHwguDLGjoC9sGYs0tesIZaCCO628U 6IxSso4c10XCLzZXNe0IlzzEh01nRGA736Dq+urOVvqy7GYjbN tKzEKq2qjavUjOgwSXwcOkE6GL9VErwrXC0raJH2zaA8jCijcE hRqhzp8Ta88VBDK+wHkkq9fCN6bPQlMK0DA6GRGbDdoCkUdwT+ Kf2kHfA0qhsU2edj83bAX15Q2ZfhuKMIEPBp6CQAR Subject: Re: [Caml-list] OCaml maintenance status / community fork (again) Am Sonntag, den 11.12.2011, 00:28 +0100 schrieb Jesper Louis Andersen: > 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. It's interesting to hear these comments. In short, in ocaml we have these options: - Full featured package management: we have this (GODI), but the community is not too large (package maintainers are always welcome!) As every full-featured system, GODI has complicated parts, and you need to invest 1-2 days before you fully understand it and can build packages. - Simplified package management: This is what OASIS-DB tries to do. Fewer features, but it is easier to create new packages. Hopefully, it will attract more developers. OASIS-DB can be integrated into full-featured systems like GODI or Debian, so the idea is also to avoid duplicate work. - Bottom end: Findlib and the build tools (ocamlbuild and omake). This already includes dependency management on the "compiler switch level" This means, the situation is not too bad. OASIS-DB is the missing link between the build tools and the high-level packaging systems. > 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. For GODI we have docs.camlcity.org. Once there is OASIS-DB, these packages will also be covered (automatically). > 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. Sounds more like it is underengineered - or leaves too many options for the users to create errors. However, there is certainly always a complexity problem in full-featured package managers. We see this problem in GODI, too, and this is probably why it is hard to convince people to help creating packages. Once a package exists, GODI is very simple to use, but getting there is not completely easy. > Multiple versions of packages > creates headaches when trying to use them Well, I do not know any package manager that supports this feature well. Finally, you have to decide to use a certain version. > (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. Sounds like this is more on the level of OASIS-DB. > 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 > } Right, this is what makes it difficult to support several versions in the same repo. > 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. Well, this is not completely independent (I can say this as developer of docs.camlcity.org). Indexing profits a lot from having a compiled version of the packages, because you have a strict name lookup then (i.e. when a name comes from a predecessor package, you can resolve this dependency easily, and you do not have to resort to fuzzy methods of lookup). Also, in docs.camlcity.org we can present the user the resulting file tree after a package is installed. This is at least interesting information. > 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... Well, we are a bit farther than you knew, obviously :-) Gerd > -- > J. > >