Hello,

=A0 Looking only at the number of packages available in th= e repositories, Opam has around 400 packages while Godi has around 170 pack= ages. Also, Opam can use "aspcud" to compute the minimal number o= f changes when installing/updating, which can make a big difference when de= pendency constraints between packages become hard to solve. I also like the= interface "=E0 la apt-get", compared to the curses interface tha= t I used with Godi.

--Fabrice

On Fri, Jul 19, 2013 at 7:22 PM, <= ;r.3@libertysurf.fr= > wrote:

=20=20 =20=20=20=20 =20=20 =20=20 Hello,
could someone explain please the relation between godi and op= am ? Is it concurrent ?
Godi has been there for some time, and works qui= te nicely. So what are differences ?
Thanks,
William

--
Fabrice LE FESSANT
Chercheur en= Informatique
INRIA Paris Rocquencourt -- OCamlPro
Programming Langua= ges and Distributed Systems

--20cf3079bcb6f2f48f04e2142af0-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id E61E77ED25 for ; Mon, 22 Jul 2013 09:20:38 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of matthieu.dubuget@gmail.com) identity=pra; client-ip=74.125.82.41; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="matthieu.dubuget@gmail.com"; x-sender="matthieu.dubuget@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of matthieu.dubuget@gmail.com designates 74.125.82.41 as permitted sender) identity=mailfrom; client-ip=74.125.82.41; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="matthieu.dubuget@gmail.com"; x-sender="matthieu.dubuget@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wg0-f41.google.com) identity=helo; client-ip=74.125.82.41; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="matthieu.dubuget@gmail.com"; x-sender="postmaster@mail-wg0-f41.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscEAHbc7FFKfVIpk2dsb2JhbABagzyDEkeGFIJcAqZEjWgEAwEjaRYOAQEBAQcLCwkUBCSCHAkBBSMPAQUIARscAQEDDAYFCw8CBRYLAgIJAwIBAgEREQEFARwTAQcBAYVyggcBAw8EmX6MAE+Cf4N6ChknDWSHdAEFDIEcjm4Hgl0OgRMDl12GI4lFP4Q6 X-IPAS-Result: AscEAHbc7FFKfVIpk2dsb2JhbABagzyDEkeGFIJcAqZEjWgEAwEjaRYOAQEBAQcLCwkUBCSCHAkBBSMPAQUIARscAQEDDAYFCw8CBRYLAgIJAwIBAgEREQEFARwTAQcBAYVyggcBAw8EmX6MAE+Cf4N6ChknDWSHdAEFDIEcjm4Hgl0OgRMDl12GI4lFP4Q6 X-IronPort-AV: E=Sophos;i="4.89,717,1367964000"; d="scan'208";a="26827662" Received: from mail-wg0-f41.google.com ([74.125.82.41]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 22 Jul 2013 09:20:38 +0200 Received: by mail-wg0-f41.google.com with SMTP id y10so2141648wgg.0 for ; Mon, 22 Jul 2013 00:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=OumZP4iZOnosPiPglXpxAdmWf7hELsPrYUchlF4GzbM=; b=x8ao1IpnDnD83p0sB0WDXlkYgzMwPBwgwKZt5OU0H+DxjPN/Lp9+Jow/sGWGRQ9phY FyMv2bQf5tbWeAYmpvjdZWLiFfclRNIvDELZO1r7WrianoNkWLEcop6BUUEYEOZXJevb UlAthEe9QKPqyZ5ReMvL2GjEZ25DjXgDMcu/kZdw1qc2SVWrzi8ayfJ/Hi/5gayiLK7v fJkiJuUEG2V1KBuGu4iAQ/WKqlF/aLSXGg/yFxbVx/fJ+/EI05xZd3A5bDtcqGD7P/wg tMOuMclmLOPtWfPH7WTiJCg0TI3SaZx8c86diqUOsr7TN5MsRQ0alCGVkAuu8V2e17No Pn0A== X-Received: by 10.194.48.116 with SMTP id k20mr18957353wjn.23.1374477638542; Mon, 22 Jul 2013 00:20:38 -0700 (PDT) Received: from [172.17.1.30] (papillon.metalscan.fr. [178.22.148.54]) by mx.google.com with ESMTPSA id mb20sm50681449wic.1.2013.07.22.00.20.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 22 Jul 2013 00:20:37 -0700 (PDT) Message-ID: <51ECDD41.6060002@gmail.com> Date: Mon, 22 Jul 2013 09:20:33 +0200 From: Matthieu Dubuget User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 CC: caml-list@inria.fr References: <383739793.214096184.1374254520546.JavaMail.root@zimbra27-e5.priv.proxad.net> In-Reply-To: <383739793.214096184.1374254520546.JavaMail.root@zimbra27-e5.priv.proxad.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] opam and godi godi can be used under Windows™. I did not succeed to install opam on a windows workstation. Note that I would prefer not having to use Windows Salutations -- Matthieu Dubuget From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id DADE47ED25 for ; Mon, 22 Jul 2013 09:35:53 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of berenger@riken.jp) identity=pra; client-ip=134.160.33.161; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of berenger@riken.jp designates 134.160.33.161 as permitted sender) identity=mailfrom; client-ip=134.160.33.161; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of postmaster@postman.riken.jp designates 134.160.33.161 as permitted sender) identity=helo; client-ip=134.160.33.161; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="postmaster@postman.riken.jp"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoBAPrf7FGGoCGhnGdsb2JhbABagzzAf4EjDgEBAQEBCAsJCRQogiQBAQUyAQU6BhELGAkWCAcJAwIBAgE0ERMGAgEBiAy2dpAdFoNoA4kmjjeGI45L X-IPAS-Result: AnoBAPrf7FGGoCGhnGdsb2JhbABagzzAf4EjDgEBAQEBCAsJCRQogiQBAQUyAQU6BhELGAkWCAcJAwIBAgE0ERMGAgEBiAy2dpAdFoNoA4kmjjeGI45L X-IronPort-AV: E=Sophos;i="4.89,717,1367964000"; d="scan'208";a="21862888" Received: from postman1.riken.jp (HELO postman.riken.jp) ([134.160.33.161]) by mail3-smtp-sop.national.inria.fr with ESMTP; 22 Jul 2013 09:35:52 +0200 Received: from postman.riken.jp (postman1.riken.jp [127.0.0.1]) by postman.riken.jp (Postfix) with SMTP id 7F06332C00EA for ; Mon, 22 Jul 2013 16:35:49 +0900 (JST) Received: from [172.27.98.109] (rikad98.riken.jp [134.160.214.98]) by postman.riken.jp (Postfix) with ESMTPA id CC7D132A008B for ; Mon, 22 Jul 2013 16:35:46 +0900 (JST) Message-ID: <51ECE0D1.8040800@riken.jp> Date: Mon, 22 Jul 2013 16:35:45 +0900 From: Francois Berenger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: caml-list@inria.fr References: <383739793.214096184.1374254520546.JavaMail.root@zimbra27-e5.priv.proxad.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.7.22.71828 Subject: Re: [Caml-list] opam and godi On 07/22/2013 03:55 PM, Fabrice Le Fessant wrote: > Hello, > > Looking only at the number of packages available in the repositories, > Opam has around 400 packages while Godi has around 170 packages. Also, > Opam can use "aspcud" to compute the minimal number of changes when > installing/updating, which can make a big difference when dependency > constraints between packages become hard to solve. I also like the > interface "� la apt-get", compared to the curses interface that I used > with Godi. I also like the apt-get/aptitude style of OPAM command lines. As an impatient user, I also feel that OPAM is way faster than GODI. > --Fabrice > > On Fri, Jul 19, 2013 at 7:22 PM, > wrote: > > Hello, > could someone explain please the relation between godi and opam ? Is > it concurrent ? > Godi has been there for some time, and works quite nicely. So what > are differences ? > Thanks, > William > > > -- > Fabrice LE FESSANT > Chercheur en Informatique > INRIA Paris Rocquencourt -- OCamlPro > Programming Languages and Distributed Systems From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 19CF27ED25 for ; Mon, 22 Jul 2013 09:45:00 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of adrien@notk.org) identity=pra; client-ip=91.121.71.147; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of adrien@notk.org designates 91.121.71.147 as permitted sender) identity=mailfrom; client-ip=91.121.71.147; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@nautica.notk.org) identity=helo; client-ip=91.121.71.147; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="postmaster@nautica.notk.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAFri7FFbeUeT/2dsb2JhbABagwaDJmm9JoENFnSCJAEBBAEjJDcLCxgCAgUTDgICDwUYMScKh2wKpXeDf4x+gSiNSYEsgl0zbgOXXAGRTYMUOoEu X-IPAS-Result: AjoFAFri7FFbeUeT/2dsb2JhbABagwaDJmm9JoENFnSCJAEBBAEjJDcLCxgCAgUTDgICDwUYMScKh2wKpXeDf4x+gSiNSYEsgl0zbgOXXAGRTYMUOoEu X-IronPort-AV: E=Sophos;i="4.89,717,1367964000"; d="scan'208";a="26831539" Received: from nautica.notk.org ([91.121.71.147]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 22 Jul 2013 09:44:59 +0200 Received: by nautica.notk.org (Postfix, from userid 1003) id 0DA8AC009; Mon, 22 Jul 2013 09:44:59 +0200 (CEST) Date: Mon, 22 Jul 2013 09:44:59 +0200 From: Adrien Nader To: "caml-list@inria.fr" Message-ID: <20130722074459.GA10640@notk.org> References: <383739793.214096184.1374254520546.JavaMail.root@zimbra27-e5.priv.proxad.net> <7b4c87b5d9aa76728e239f0a2172b795.squirrel@gps.dynxs.de> <6796313D-9F02-4C70-87D9-8DC9BC896028@recoil.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Caml-list] opam and godi On Sun, Jul 21, 2013, Yaron Minsky wrote: > While I appreciate the work that Gerd has done on GODI, I do think > that OPAM is a significant improvement over GODI. > > From an end-user-experience perspective, I've found OPAM to be > considerably smoother than GODI. In addition to having what I > consider to be a better user interface, upgrading of packages in OPAM > has been very smooth overall. I found upgrades in GODI to be pretty > tricky, with many upgrades ending in failure for one reason or > another. I suspect this has something to do with the system for > handling of dependencies in OPAM, which has taken quite a bit of work > to get right from what I understand. I haven't had such issues that were caused by godi itself. All of the issues I've had were caused by broken sources, packaging or old ones. I believe the main difference between opam and godi lies in git as Anil mentionned. By relying on git and taking advantage of its flexibility, it makes modifying package much easier. Let's take the example of ocamldsort. It's in godi at version 0.14.1 and I'd like to see it at version >= 0.15. It seems to me it's only a matter of bumping the version, everything works the same. The work involved with GODI for such a small change seems heavier then with opam (slightly more steps, the need to contact the current package manager, svn). It's a slower process but at the same time, it seems to me that almost all of the updates that get to godi users work well. With opam, I've seen broken packages more often but at the same time they get fixed more quickly. In the end, maybe you have: - godi, slower package updates but usually more stable; bugs in packages are less common but when they exist, they can also take time to fix - opam, many more updates, maybe too many, packages get less testing before they reach others (if you want new software, you can't have a week of testing between each release) NB: don't get me wrong, I don't blame any package maintainer or package on slow updates or bugs: many issues arise when software is used on 10 different setups (different CPUs, different OS, ....) > In addition, the ability to easily handle multiple compilers in OPAM > is also a big win, from my perspective. I think it makes it much > easier to try out and give feedback on upcoming compiler versions, > which is good for the community as a whole. (Plus, trying out > bleeding-edge compiler patches is fun...) Every time I hear this, I'm very surprised: I simply change my PATH environment variable for the current shell I'm in and get the same effect For instance, my shell history has this: export PATH=$(echo $PATH | sed 's;opt/ocaml;home/adrien/projects/ocaml-ty;g') It's very simple and works even though I haven't installed ocaml-ty through godi. PS: Gerd, I believe the "Packager FAQ" needs some pruning. ;-) -- Adrien Nader From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 0EACC81798 for ; Mon, 22 Jul 2013 09:46:59 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of adrien@notk.org) identity=pra; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of adrien@notk.org designates 91.121.71.147 as permitted sender) identity=mailfrom; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@nautica.notk.org) identity=helo; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="postmaster@nautica.notk.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0JAFri7FFbeUeT/2dsb2JhbABagwaDJmm6NYJsBAGBDRZ0giQBAQUjDwFGEAsYAgIFEw4CAg8FGDGIJ6V3kH2BKI1XgRcHgl0zbgOXXAGRTYMUOg X-IPAS-Result: Ar0JAFri7FFbeUeT/2dsb2JhbABagwaDJmm6NYJsBAGBDRZ0giQBAQUjDwFGEAsYAgIFEw4CAg8FGDGIJ6V3kH2BKI1XgRcHgl0zbgOXXAGRTYMUOg X-IronPort-AV: E=Sophos;i="4.89,717,1367964000"; d="scan'208";a="21864451" Received: from nautica.notk.org ([91.121.71.147]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 22 Jul 2013 09:46:58 +0200 Received: by nautica.notk.org (Postfix, from userid 1003) id B6B28C009; Mon, 22 Jul 2013 09:46:57 +0200 (CEST) Date: Mon, 22 Jul 2013 09:46:57 +0200 From: Adrien Nader To: Francois Berenger Cc: caml-list@inria.fr Message-ID: <20130722074657.GB10640@notk.org> References: <383739793.214096184.1374254520546.JavaMail.root@zimbra27-e5.priv.proxad.net> <51ECE0D1.8040800@riken.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <51ECE0D1.8040800@riken.jp> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Caml-list] opam and godi On Mon, Jul 22, 2013, Francois Berenger wrote: > On 07/22/2013 03:55 PM, Fabrice Le Fessant wrote: > >Hello, > > > > Looking only at the number of packages available in the repositories, > >Opam has around 400 packages while Godi has around 170 packages. Also, > >Opam can use "aspcud" to compute the minimal number of changes when > >installing/updating, which can make a big difference when dependency > >constraints between packages become hard to solve. I also like the > >interface "à la apt-get", compared to the curses interface that I used > >with Godi. > > I also like the apt-get/aptitude style of OPAM command lines. > > As an impatient user, I also feel that OPAM is way faster than GODI. As far as I can tell, godi_console is now a native-compiled executable while it used to be byte-compiled before. This has made it *WAY* faster (at least 5 times faster according to my testing earlier). I really hated these 10-15 seconds of waiting. -- Adrien Nader From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 83B1F7ED25 for ; Mon, 22 Jul 2013 10:06:53 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of edwin+ml-ocaml@etorok.net) identity=pra; client-ip=176.9.138.55; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="edwin+ml-ocaml@etorok.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of edwin+ml-ocaml@etorok.net designates 176.9.138.55 as permitted sender) identity=mailfrom; client-ip=176.9.138.55; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="edwin+ml-ocaml@etorok.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@mail.etorok.net designates 176.9.138.55 as permitted sender) identity=helo; client-ip=176.9.138.55; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="postmaster@mail.etorok.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFAArn7FGwCYo3/2dsb2JhbABagmUhwTWBDRZ0giQBAQQBQAEBBSYLAgQLCxgJFg8JAwIBAgFFEwgCEAqHbAcDpHSEQgEFK4x4Bo5xgSyDfokljjuRTYMVgWc X-IPAS-Result: AjAFAArn7FGwCYo3/2dsb2JhbABagmUhwTWBDRZ0giQBAQQBQAEBBSYLAgQLCxgJFg8JAwIBAgFFEwgCEAqHbAcDpHSEQgEFK4x4Bo5xgSyDfokljjuRTYMVgWc X-IronPort-AV: E=Sophos;i="4.89,717,1367964000"; d="scan'208";a="26836487" Received: from mail.etorok.net ([176.9.138.55]) by mail2-smtp-roc.national.inria.fr with ESMTP; 22 Jul 2013 10:06:51 +0200 Received: from [IPv6:2a02:2f09:4180:7400:fc85:8090:f9:e910] (unknown [IPv6:2a02:2f09:4180:7400:fc85:8090:f9:e910]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.etorok.net (Postfix) with ESMTPSA id DB99F46D8 for ; Mon, 22 Jul 2013 10:06:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=etorok.net; s=mailout; t=1374480410; bh=HWeZz/3erDyEVyESYYrKNyj631xQabwd2VQ1Y2TTLQA=; l=4733; h=Date:From:To:References:In-Reply-To:From; b=xYei5mC0jiolI5/7k4c+LU7lYPdB8ueDdxYotfbZDZ2KEnpRtgQE6cLBHcfkupVUq wTVRuLsSjBGW5FsIYbivTke5t3TRbo8oWU1JPEwYx0eGBTOd6Q+JRlXk8hKdKna942 1UH4Eu3ndxZFNDRj/eEU7j5pJCcORA/46itX928I= Message-ID: <51ECE818.9060908@etorok.net> Date: Mon, 22 Jul 2013 11:06:48 +0300 From: =?ISO-8859-1?Q?T=F6r=F6k_Edwin?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: caml-list@inria.fr References: <383739793.214096184.1374254520546.JavaMail.root@zimbra27-e5.priv.proxad.net> <7b4c87b5d9aa76728e239f0a2172b795.squirrel@gps.dynxs.de> <6796313D-9F02-4C70-87D9-8DC9BC896028@recoil.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Subject: Re: [Caml-list] opam and godi On 07/21/2013 05:43 PM, Yaron Minsky wrote: > While I appreciate the work that Gerd has done on GODI, I do think > that OPAM is a significant improvement over GODI. I thought I'd share why and how I started using OPAM. I have used GODI briefly when I had to install some application on RHEL, which had some old version of the OCaml compiler at the time, and missing most of the libraries I needed. GODI was very smooth to use for that purpose, and I'm glad that someone dedicated time to writing and maintaining it. My main system is Debian though, and I was quite happy with the OCaml packages provided by the distribution, so I didn't have a reason to use GODI (or another source-based package manager) on Debian. After OCaml 4.00 got released I eventually needed a source-based package manager, and when OPAM was available I gave it a try. It was fairly simple to use and worked well (except some small issues with upgrades ocasionally), and it is the main package manager I use for OCaml now. > > From an end-user-experience perspective, I've found OPAM to be > considerably smoother than GODI. In addition to having what I > consider to be a better user interface, opam's simplistic interface is closer to apt-get, which I use and like. GODI's ncurses-like interface is more like aptitude's curses-interface ... which I don't use. It also has a command-line interface, which I haven't tried (the docs place little emphasis on it). So perhaps the less-advanced interface of opam wins exactly because of that. Or maybe it is because GODI already existed at the time I started learning OCaml, and OPAM is the new tool for me that came much later, and I like it only because I used it more recently. There is more to OPAM though, 'opam switch' is definitely a useful feature, as is the ability to use the system's OCaml compiler (I may be wrong here, does GODI support that?). Having said that I would've preferred if OPAM and GODI worked together rather than having a completely new project. In the end I think what would be best is if OASIS could be automatically converted to OPAM, GODI, DEB and RPM packages, and then upstream projects would only need to worry about supplying one correct _oasis file, and OPAM/GODI could use that directly, so that all build/depedency etc. fixes eventually end up in all repositories. And of course the conversion shouldn't be one-time only, whenever _oasis is updated the changes should propagate, perhaps with some small addons _oasis.debian, _oasis.opam, etc. for things that cannot be expressed in OASIS directly (or which doesn't make sense to have in _oasis, like name of downstream maintainers). Packagers should prefer to update these files, instead of their distribution-specific ones, and have the distro-specific build descriptions automatically generated from this. I'm aware that OASIS is not perfect either (there was a discussion earlier about installing docs), but I think that improving it (and the conversion tools) would eventually get us a simple unified build/package description and then library/application authors and end-users shouldn't care what package manager they use: they'd get a similar quality experience. And whenever a bug is discovered by the user of one package manager, the fix is applied to all. I'm aware that oasis2deb, oasis2opam exist, does oasis2godi and oasis2rpm exist? How does OASIS-DB fit into this picture? There is of course the question what to do about packages that do not provide an _oasis file, maybe a start would be opam2oasis (and godi2oasis?) that would provide a dummy _oasis file that just uses the custom Makefiles of the package, but provide all the metadata that the package does. > upgrading of packages in OPAM > has been very smooth overall. I found upgrades in GODI to be pretty > tricky, with many upgrades ending in failure for one reason or > another. I've had OPAM upgrades fail due to bugs in packages / missing system dependencies a few times, and there is a bug open about support for rollbacks, so it is not as smooth as "apt-get" yet. I haven't used GODI long enough to be able to compare it with OPAM on this regard. > I suspect this has something to do with the system for > handling of dependencies in OPAM, which has taken quite a bit of work > to get right from what I understand. > > In addition, the ability to easily handle multiple compilers in OPAM > is also a big win, from my perspective. I think it makes it much > easier to try out and give feedback on upcoming compiler versions, > which is good for the community as a whole. (Plus, trying out > bleeding-edge compiler patches is fun...) Agreed. Best regards, --Edwin From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 728B281799 for ; Mon, 22 Jul 2013 14:20:44 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=212.227.126.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=212.227.126.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@moutng.kundenserver.de designates 212.227.126.171 as permitted sender) identity=helo; client-ip=212.227.126.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="postmaster@moutng.kundenserver.de"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoDAJAi7VHU436rbWdsb2JhbABagztQrBSUHIEOFg4LCwwGFgMlgiQBAQQBDG0FCwUGGC5XBhMJCId5Cgi3C4llhX4NJgeDfgOOZRiFCYUAjlWEYw X-IPAS-Result: AgoDAJAi7VHU436rbWdsb2JhbABagztQrBSUHIEOFg4LCwwGFgMlgiQBAQQBDG0FCwUGGC5XBhMJCId5Cgi3C4llhX4NJgeDfgOOZRiFCYUAjlWEYw X-IronPort-AV: E=Sophos;i="4.89,719,1367964000"; d="scan'208";a="26872226" Received: from moutng.kundenserver.de ([212.227.126.171]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 22 Jul 2013 14:20:43 +0200 Received: from office1.lan.sumadev.de (dslb-084-059-078-221.pools.arcor-ip.net [84.59.78.221]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MXCef-1UdvMi3MHN-00VuCV; Mon, 22 Jul 2013 14:20:42 +0200 Received: from gps.dynxs.de (localhost [127.0.0.1]) by office1.lan.sumadev.de (Postfix) with ESMTP id EDFE4C00CF; Mon, 22 Jul 2013 14:20:40 +0200 (CEST) Received: from 84.107.248.22 (SquirrelMail authenticated user gerd) by gps.dynxs.de with HTTP; Mon, 22 Jul 2013 14:20:41 +0200 Message-ID: In-Reply-To: <51ECE818.9060908@etorok.net> References: <383739793.214096184.1374254520546.JavaMail.root@zimbra27-e5.priv.proxad.net> <7b4c87b5d9aa76728e239f0a2172b795.squirrel@gps.dynxs.de> <6796313D-9F02-4C70-87D9-8DC9BC896028@recoil.org> <51ECE818.9060908@etorok.net> Date: Mon, 22 Jul 2013 14:20:41 +0200 From: "Gerd Stolpmann" To: =?iso-8859-1?Q?=22T=F6r=F6k_Edwin=22?= Cc: caml-list@inria.fr User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Provags-ID: V02:K0:1VPoNF/NVK/HepdGwzc3qTy//VwnlsxaGIA4g6kPYOx xDLdy5mmF6IndZHfFG48wgTWZVdX6owt7ETvR+l0wDlllSzJTD 9hpC1LXWNuE00Jg7uJtCXlucRoa5sXZo+ZHNXXv1by+fNPAWUk rQlsLT0viNpzSZWTleB0H2kozoU42FjiIqi29rCPGEdyGk21S8 2lNJcKlOoVPaqTHOKTquEecT+ah5vqgSlONcaqBg8KFVXD1SWn kdeha2N8S21cCg4tRA8tEXg4J0T/LPQHu1v7l3gnBlToEfaMvS KM6P/EQm6bgTydtwo9q5VauT7tPPaNyYGFGT17gr0DdszmmWlx 1NArifuAsYH02GFoZzxLNTu32eUT90YgAuwC7whmWw8F8JSUHa d2NgzyfysvW4g== Subject: Re: [Caml-list] opam and godi > On 07/21/2013 05:43 PM, Yaron Minsky wrote: >> While I appreciate the work that Gerd has done on GODI, I do think >> that OPAM is a significant improvement over GODI. T=F6r=F6k Edwin wrote: > opam's simplistic interface is closer to apt-get, which I use and like. > GODI's ncurses-like interface is more like aptitude's curses-interface ... > which I don't use. > It also has a command-line interface, which I haven't tried (the docs > place little emphasis on it). It's not that much different to apt-get. The curses-like interface is more for beginners, or getting started. > There is more to OPAM though, 'opam switch' is definitely a useful > feature, as is the ability to use the system's OCaml compiler (I may be > wrong here, does GODI support that?). Partially. You can demand a specific svn version of the compiler, and then rebuild everything, but it's not wrapped up as command. Maybe something to add (this would fit well into the framework). > Having said that I would've preferred if OPAM and GODI worked together > rather than having a completely new project. > In the end I think what would be best is if OASIS could be automatically > converted to OPAM, GODI, DEB and RPM packages, and then upstream projects > would only need to worry about supplying one correct _oasis file, and > OPAM/GODI could use that directly, so that all build/depedency etc. fixes > eventually end up in all repositories. Fully supporting that. > And of course the conversion shouldn't be one-time only, whenever _oasis > is updated the changes should propagate, perhaps with some small addons > _oasis.debian, _oasis.opam, etc. for things that cannot be expressed in > OASIS directly (or which doesn't make sense to have in _oasis, like name > of downstream maintainers). > Packagers should prefer to update these files, instead of their > distribution-specific ones, and have the distro-specific build > descriptions automatically generated from this. > > I'm aware that OASIS is not perfect either (there was a discussion earlier > about installing docs), but I think that improving it (and the conversion > tools) would eventually get us a simple unified build/package description > and then library/application authors and end-users shouldn't care what > package manager they use: they'd get a similar quality experience. And > whenever a bug is discovered by the user of one package manager, the fix > is applied to all. > > I'm aware that oasis2deb, oasis2opam exist, does oasis2godi and oasis2rpm > exist? There is a script for converting oasis to GODI, godi_oasis_import, which is available now in GODI. > How does OASIS-DB fit into this picture? GODI even automatically imports packages from OASIS-DB into its own repository, with nightly refresh. This is still a bit experimental, and needs to be activated by the user in order to get the packages (described here: http://godi.camlcity.org/godi/oasis.html). The GODI autobuilder also tries to build the oasis packages. See the list here (scroll down until the package names start with oasis): https://godirepo.camlcity.org/openapps/autoui.cgi As you can see, it is only partially successful. That's basically because there is no QA on OASIS-DB. > There is of course the question what to do about packages that do not > provide an _oasis file, maybe a start would be opam2oasis (and > godi2oasis?) that would provide a dummy _oasis file that just uses the > custom Makefiles of the package, but provide all the metadata that the > package does. No, all package managers should unite in this point, and only accept packages with oasis support. (Btw, that's homework for me.) Just do it the same way as we did when requiring findlib. The question here is whether oasis is already mature enough to require it. Gerd --=20 Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de Creator of GODI and camlcity.org. Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de *** Searching for new projects! Need consulting for system *** programming in Ocaml? Gerd Stolpmann can help you. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 246E181799 for ; Mon, 22 Jul 2013 14:34:10 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=212.227.17.8; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=212.227.17.8; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of postmaster@moutng.kundenserver.de designates 212.227.17.8 as permitted sender) identity=helo; client-ip=212.227.17.8; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="postmaster@moutng.kundenserver.de"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYCANkl7VHU4xEIbWdsb2JhbABagztQwDCBDhYOCwsMBhYDJYIkAQEEAXkFCwUGGC5XBhMJCId5Cgi3EollhX4NJgeDfgOOZRiKCY5VhGM X-IPAS-Result: AhYCANkl7VHU4xEIbWdsb2JhbABagztQwDCBDhYOCwsMBhYDJYIkAQEEAXkFCwUGGC5XBhMJCId5Cgi3EollhX4NJgeDfgOOZRiKCY5VhGM X-IronPort-AV: E=Sophos;i="4.89,719,1367964000"; d="scan'208";a="21897262" Received: from moutng.kundenserver.de ([212.227.17.8]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 22 Jul 2013 14:34:09 +0200 Received: from office1.lan.sumadev.de (dslb-084-059-078-221.pools.arcor-ip.net [84.59.78.221]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MUCR8-1UbQhu0w66-00QOsU; Mon, 22 Jul 2013 14:34:08 +0200 Received: from gps.dynxs.de (localhost [127.0.0.1]) by office1.lan.sumadev.de (Postfix) with ESMTP id 84248C00CF; Mon, 22 Jul 2013 14:34:07 +0200 (CEST) Received: from 84.107.248.22 (SquirrelMail authenticated user gerd) by gps.dynxs.de with HTTP; Mon, 22 Jul 2013 14:34:07 +0200 Message-ID: In-Reply-To: <20130722074657.GB10640@notk.org> References: <383739793.214096184.1374254520546.JavaMail.root@zimbra27-e5.priv.proxad.net> <51ECE0D1.8040800@riken.jp> <20130722074657.GB10640@notk.org> Date: Mon, 22 Jul 2013 14:34:07 +0200 From: "Gerd Stolpmann" To: "Adrien Nader" Cc: "Francois Berenger" , caml-list@inria.fr User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Provags-ID: V02:K0:MZwzz4xo0pLTNvOmRFmIxb8zLij/J8pgiy5/YHbfZLD eew5yCgcsSIwS4BqWpl/ANvss+HKA/NhblosIC4bQX+QLQV0Tu v4aV2HmN9cOj6joDypW5O1k9MAgSa0LGxk/3FtCYkl92hVMgfG xdTBFK+DWXc2+0hUYywUlKyGMV1l0XUJmmu+ScASlMcz05Wczl L2nJLKa0oE0ftL9ebe9hJaLeljU8flAuhosOHpu1XsdmC4F8t3 C80NhT2WFud55TY5ItnIyniHOPphFWAHBIz5xvwgXsP27iF/Xt RG5biSW+1ngfKoctwCT3ghUtufT1dASjiBtp1OoSJQlIi+BhYy 2d1CP6ELiy5okoT5VpUB5tGM8KzDXZne1eUVEHE/Ib70h0ZbP3 mkDiMIVYGiTvwGLvgwNqC4ITa16s8vEGww= Subject: Re: [Caml-list] opam and godi > On Mon, Jul 22, 2013, Francois Berenger wrote: >> On 07/22/2013 03:55 PM, Fabrice Le Fessant wrote: >> >Hello, >> > >> > Looking only at the number of packages available in the >> repositories, >> >Opam has around 400 packages while Godi has around 170 packages. Also, >> >Opam can use "aspcud" to compute the minimal number of changes when >> >installing/updating, which can make a big difference when dependency >> >constraints between packages become hard to solve. I also like the >> >interface "=C3=A0 la apt-get", compared to the curses interface that I = used >> >with Godi. >> >> I also like the apt-get/aptitude style of OPAM command lines. >> >> As an impatient user, I also feel that OPAM is way faster than GODI. > > As far as I can tell, godi_console is now a native-compiled executable > while it used to be byte-compiled before. > This has made it *WAY* faster (at least 5 times faster according to my > testing earlier). I really hated these 10-15 seconds of waiting. Actually, this is fixed since I did a performance audit, giving special attention to such problems. The natively-compiled command has always been built, but the bug was that it wasn't installed :-(. Also, there is now better caching of package scanning results. Gerd --=20 Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de Creator of GODI and camlcity.org. Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de *** Searching for new projects! Need consulting for system *** programming in Ocaml? Gerd Stolpmann can help you. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id F201181799 for ; Mon, 22 Jul 2013 14:56:17 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=212.227.126.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=212.227.126.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@moutng.kundenserver.de designates 212.227.126.171 as permitted sender) identity=helo; client-ip=212.227.126.171; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="postmaster@moutng.kundenserver.de"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYCAMIq7VHU436rbWdsb2JhbABagztQrg6SIoEOFg4LCwwGFgMlgiQBAQVHJwQHEAUGDgoNIUUSBhMJCAECCodgAxMIqhCEKwOIaIllhQxyMweDfgOOZRiKCY5VhGOBaA X-IPAS-Result: AhYCAMIq7VHU436rbWdsb2JhbABagztQrg6SIoEOFg4LCwwGFgMlgiQBAQVHJwQHEAUGDgoNIUUSBhMJCAECCodgAxMIqhCEKwOIaIllhQxyMweDfgOOZRiKCY5VhGOBaA X-IronPort-AV: E=Sophos;i="4.89,719,1367964000"; d="scan'208";a="26876972" Received: from moutng.kundenserver.de ([212.227.126.171]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 22 Jul 2013 14:56:17 +0200 Received: from office1.lan.sumadev.de (dslb-084-059-078-221.pools.arcor-ip.net [84.59.78.221]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0LmL6w-1USjqn1SCo-00ZuEy; Mon, 22 Jul 2013 14:55:59 +0200 Received: from gps.dynxs.de (localhost [127.0.0.1]) by office1.lan.sumadev.de (Postfix) with ESMTP id 9C206C00CF; Mon, 22 Jul 2013 14:55:58 +0200 (CEST) Received: from 84.107.248.22 (SquirrelMail authenticated user gerd) by gps.dynxs.de with HTTP; Mon, 22 Jul 2013 14:55:59 +0200 Message-ID: In-Reply-To: References: <383739793.214096184.1374254520546.JavaMail.root@zimbra27-e5.priv.proxad.net> <7b4c87b5d9aa76728e239f0a2172b795.squirrel@gps.dynxs.de> <6796313D-9F02-4C70-87D9-8DC9BC896028@recoil.org> Date: Mon, 22 Jul 2013 14:55:59 +0200 From: "Gerd Stolpmann" To: "Yaron Minsky" Cc: "Anil Madhavapeddy" , r.3@libertysurf.fr, "caml-list@inria.fr" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Provags-ID: V02:K0:ESnFfqCDnnkRlu3YYvu9av1psu1V5WS0Gl4Y1IZSkTJ zK1cBgn6Ga2GkGQZp4NI0c9lO7o6wAZ3SNDAJ3/ZycTpXb0hZ2 oqzD8FpXFmF9c+T37cdffTuOKGnHiIs9wkb4vT7kspXmlShvuw 8p7cSlYitXK46EM35gV2AnKqswKuKJotWqb7ySEFCdMc8VYXsr +C2GhvQoZKdU0u0SB2Ma87i+sQsdi0nv06fMENyNq8U5+5afjC gFJbSXZOLbsZcgEFOXU8FM2HZXPlB82eaRsGcU31lafiAcuTd2 DwoCR8H0O7VlNAVAPZfcxUu1XIyWM990QHhaYBEB+WjZt/SDEm Ufhs8MEGK1Q0jw3gtLkRHt46GWz/0i8R3agDOC92ElsYSwaT4l iM/h7VB/TVcG4XEo8GyZDXCL6uwij3Yknw= Subject: Re: [Caml-list] opam and godi Sad to read such FUD here. The truth is that the company Yaron is working for never managed to create good Core packages. I don't know what the reason is, but I guess so it is within this company, since other people with fewer resources mastered similar tasks well. This is something I was always puzzled about, since initially there was good cooperation with this company. So far I've removed Core from GODI because it misses QA standards, and have no plans to add it again. Gerd Yaron Minsky wrote: > While I appreciate the work that Gerd has done on GODI, I do think > that OPAM is a significant improvement over GODI. > > From an end-user-experience perspective, I've found OPAM to be > considerably smoother than GODI. In addition to having what I > consider to be a better user interface, upgrading of packages in OPAM > has been very smooth overall. I found upgrades in GODI to be pretty > tricky, with many upgrades ending in failure for one reason or > another. I suspect this has something to do with the system for > handling of dependencies in OPAM, which has taken quite a bit of work > to get right from what I understand. > > In addition, the ability to easily handle multiple compilers in OPAM > is also a big win, from my perspective. I think it makes it much > easier to try out and give feedback on upcoming compiler versions, > which is good for the community as a whole. (Plus, trying out > bleeding-edge compiler patches is fun...) > > With the arrival of OPAM, for the first time I feel good about > recommending that new users try out libraries with significant > dependencies like Core, since installing such libraries is now really > quite simple. > > y > > On Sun, Jul 21, 2013 at 10:20 AM, Anil Madhavapeddy > wrote: >> On 21 Jul 2013, at 14:54, "Gerd Stolpmann" >> wrote: >>> >>>> Hello, >>>> could someone explain please the relation between godi and opam ? Is >>>> it >>>> concurrent ? >>>> Godi has been there for some time, and works quite nicely. So what are >>>> differences ? >>> >>> Hi, >>> >>> both are independent projects. OPAM is a younger project, and I don't >>> really know what the motivation behind it is (in addition to the >>> generic >>> motication to hack something). There were initially claims to make it >>> is >>> easier to package software up, but what I've seen is actually not much >>> different from GODI (actually even worse now that GODI allows it to >>> fully >>> automate package releases). >> >> The answer's right there on the front page: >> >> "OPAM is a source-based package manager for OCaml. It supports multiple >> simultaneous compiler installations, flexible package constraints, and a >> Git-friendly development workflow." >> >>> The feature sets are not the same, and some stuff works better in OPAM >>> and >>> some in GODI. As I'm advocating the latter, let me point out some >>> features >>> where I think GODI is better: >> >> Feature minutiae aside, I'd say the biggest benefit of OPAM is the more >> open development workflow. It's easier for people to maintain their >> own branches and contribute changes to the central repository. >> >> Let's look at the stable repository "pulse": >> https://github.com/OCamlPro/opam-repository/pulse/monthly >> >> It tells us that in the last month, there have been 30 authors that have >> pushed 167 package updates. These have all come in as pull requests that >> can still be browsed. For example, see the latest Core from Jane >> Street: >> https://github.com/OCamlPro/opam-repository/pulls?state=3Dclosed >> >> Several development groups also maintain their own remotes without any >> need to depend on the central repository. For example, see Citrix's: >> https://github.com/xapi-project/opam-repo-dev/tree/master/packages >> >> As Gerd points out, GODI is an older and more mature project. I find >> OPAM more useful for my own personal development workflow though. You >> should try both out and see which one you prefer. >> >> cheers, >> Anil >> >> -- >> Caml-list mailing list. Subscription management and archives: >> https://sympa.inria.fr/sympa/arc/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > > --=20 Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de Creator of GODI and camlcity.org. Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de *** Searching for new projects! Need consulting for system *** programming in Ocaml? Gerd Stolpmann can help you. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 7E3B081799 for ; Mon, 22 Jul 2013 15:30:53 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of anil@recoil.org) identity=pra; client-ip=89.16.177.154; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="anil@recoil.org"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of anil@recoil.org) identity=mailfrom; client-ip=89.16.177.154; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="anil@recoil.org"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@dark.recoil.org) identity=helo; client-ip=89.16.177.154; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="postmaster@dark.recoil.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8GAPYy7VFZELGadGdsb2JhbABagzutRZM7gSQOAQwVCDyCJAEBBAE6PwULC0ZXBhOICgYECLc6BI5lgTEHgxBuA5ddlGCBZyQ X-IPAS-Result: Am8GAPYy7VFZELGadGdsb2JhbABagzutRZM7gSQOAQwVCDyCJAEBBAE6PwULC0ZXBhOICgYECLc6BI5lgTEHgxBuA5ddlGCBZyQ X-IronPort-AV: E=Sophos;i="4.89,719,1367964000"; d="scan'208";a="26882522" Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) ([89.16.177.154]) by mail2-smtp-roc.national.inria.fr with SMTP; 22 Jul 2013 15:30:53 +0200 Received: (qmail 19480 invoked by uid 634); 22 Jul 2013 13:30:53 -0000 X-Spam-Level: * X-Spam-Check-By: dark.recoil.org Received: from volstagg-0.srg.cl.cam.ac.uk (HELO clink-4.office) (128.232.32.232) (smtp-auth username remote@recoil.org, mechanism cram-md5) by dark.recoil.org (qpsmtpd/0.84) with ESMTPA; Mon, 22 Jul 2013 14:30:52 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 $1503$) From: Anil Madhavapeddy In-Reply-To: <20130722074459.GA10640@notk.org> Date: Mon, 22 Jul 2013 14:30:51 +0100 Cc: caml-list@inria.fr, "opam-devel@lists.ocaml.org" Content-Transfer-Encoding: 7bit Message-Id: <66667E06-8E92-4CB8-BF59-578E1E961AC0@recoil.org> References: <383739793.214096184.1374254520546.JavaMail.root@zimbra27-e5.priv.proxad.net> <7b4c87b5d9aa76728e239f0a2172b795.squirrel@gps.dynxs.de> <6796313D-9F02-4C70-87D9-8DC9BC896028@recoil.org> <20130722074459.GA10640@notk.org> To: Adrien Nader X-Mailer: Apple Mail (2.1503) X-Virus-Checked: Checked by ClamAV on dark.recoil.org Subject: Re: [Caml-list] opam and godi On 22 Jul 2013, at 08:44, Adrien Nader wrote: > In the end, maybe you have: > - godi, slower package updates but usually more stable; bugs in packages > are less common but when they exist, they can also take time to fix > - opam, many more updates, maybe too many, packages get less testing > before they reach others (if you want new software, you can't have a > week of testing between each release) > > NB: don't get me wrong, I don't blame any package maintainer or package > on slow updates or bugs: many issues arise when software is used on 10 > different setups (different CPUs, different OS, ....) This is absolutely true. I've been assembling a little machine pool of 'exotic architectures' that make it easier to test all the various permutations. OPAM has a vestigial autobuilder now that runs through a bunch of different platforms. For a *temporary* URL with our development version, see: https://ocaml-www3.ocamllabs.cl.cam.ac.uk/github/OCamlPro/opam-repository Once the teething issues are sorted, David Sheets has also written Github bindings so that work will be queued up directly from a Github pull request. Anyone submitting a report can have their package tested on systems they don't normally have access to. This will in turn let us do acceptance tests before merging pull requests into the 'stable' OPAM repository. I really like the Git workflow behind all this. It basically reflects how we work with OCaml in an industrial setting: pool up a sequence of local changes (across multiple repositories), publish them to an internal OPAM remote, and then issue pull requests upstream until you hit the central stable repository. At no point do you have to block waiting for someone else to do something for you, unless it's the default central repository that Thomas and I monitor. I'm also very pleased to announce that Rackspace (who use OCaml via the Xen Cloud toolstack) have recently donated a significant number of VMs to power all the builds behind this. We can use this infrastructure to securely run unit tests: we just need to set up a "gold image" VM with the build, unplugging its external network interface, run the test, and then replug it back into the network. All via HTTP interfaces, with feedback sent back to the package maintainer via the Github pull request interface. -anil (PS: for those concerned about an over-dependence on Github, I'm currently evaluating Gitlab, which Jeremy Yallop pointed out to me -- it seems a good candidate to mirror all this activity somewhere else, while still using Github as a primary source). From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id C8D2381799 for ; Mon, 22 Jul 2013 15:51:50 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of dave.scott@eu.citrix.com) identity=pra; client-ip=46.33.159.39; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="Dave.Scott@eu.citrix.com"; x-sender="dave.scott@eu.citrix.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of Dave.Scott@eu.citrix.com designates 46.33.159.39 as permitted sender) identity=mailfrom; client-ip=46.33.159.39; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="Dave.Scott@eu.citrix.com"; x-sender="Dave.Scott@eu.citrix.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of postmaster@SMTP.EU.CITRIX.COM designates 46.33.159.39 as permitted sender) identity=helo; client-ip=46.33.159.39; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="Dave.Scott@eu.citrix.com"; x-sender="postmaster@SMTP.EU.CITRIX.COM"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoBAJ447VEuIZ8nnGdsb2JhbABagzsBwH+BDxYOAQEBAQEICwkJFCiCJAEBBAE4QAEQCyEWDwkDAgECAUUGDQEHAQGIBgoIt0sEkBYHg34DiHCVEI49Ow X-IPAS-Result: ApoBAJ447VEuIZ8nnGdsb2JhbABagzsBwH+BDxYOAQEBAQEICwkJFCiCJAEBBAE4QAEQCyEWDwkDAgECAUUGDQEHAQGIBgoIt0sEkBYHg34DiHCVEI49Ow X-IronPort-AV: E=Sophos;i="4.89,719,1367964000"; d="scan'208";a="21906556" Received: from smtp.eu.citrix.com ([46.33.159.39]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 22 Jul 2013 15:51:26 +0200 X-IronPort-AV: E=Sophos;i="4.89,719,1367971200"; d="scan'208";a="6944763" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 22 Jul 2013 13:51:25 +0000 Received: from [10.80.239.111] (10.80.239.111) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Mon, 22 Jul 2013 14:51:24 +0100 Message-ID: <51ED38F5.2030705@eu.citrix.com> Date: Mon, 22 Jul 2013 14:51:49 +0100 From: David Scott User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Anil Madhavapeddy CC: Gerd Stolpmann , , References: <383739793.214096184.1374254520546.JavaMail.root@zimbra27-e5.priv.proxad.net> <7b4c87b5d9aa76728e239f0a2172b795.squirrel@gps.dynxs.de> <6796313D-9F02-4C70-87D9-8DC9BC896028@recoil.org> In-Reply-To: <6796313D-9F02-4C70-87D9-8DC9BC896028@recoil.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] opam and godi On 21/07/13 15:20, Anil Madhavapeddy wrote: [ snip ] > Feature minutiae aside, I'd say the biggest benefit of OPAM is the more > open development workflow. It's easier for people to maintain their > own branches and contribute changes to the central repository. [ snip ] > Several development groups also maintain their own remotes without any > need to depend on the central repository. For example, see Citrix's: > https://github.com/xapi-project/opam-repo-dev/tree/master/packages I really like the git-style development workflow encouraged by OPAM. Note I'm not a GODI user so I don't know if the same thing can be done there. The packages you link to above are in development, and having our own package repo in git means that we can use pull requests both to propose changes to the code, and to quickly update the packages. As each package matures, we can then make pull requests to the main OPAM repo. Lowering the effort needed to create and maintain a package has had another useful side-effect (IMHO). Previously while working on Xen(Server) we created a few large monolithic libraries which were tending (perhaps) towards becoming 'frameworks' (in a bad way). Now we've started isolating distinct areas of functionality and chopping them off into independently usable libs, or dropping them altogether in favour of better alternatives (e.g. we're dropping a custom HTTP server library in favour of cohttp). This kind of strong isolation between components will make the code easier for us to maintain. Regarding binary packages: for our use-cases binary package support via OPAM or GODI isn't necessary. We'd like to distribute binary packages of our software through Linux distributions, which means we're keen to create .rpms and .debs in the usual way. Typically our stuff runs as services, which means you need to write distro-specific code to integrate with systemd/upstart anyway, so there's little an automatic tool can do to help. Cheers, Dave Scott XenServer System Architect, Citrix From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 827AC81799 for ; Mon, 22 Jul 2013 20:30:50 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of yminsky@janestreet.com) identity=pra; client-ip=38.105.200.229; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of yminsky@janestreet.com designates 38.105.200.229 as permitted sender) identity=mailfrom; client-ip=38.105.200.229; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@tot-dmz-mxout1.janestreet.com) identity=helo; client-ip=38.105.200.229; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="postmaster@tot-dmz-mxout1.janestreet.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngBAHt57VEmacjlnGdsb2JhbABbgztQrhCSIoEOHg4BAQEBAQYNCQkUKIIkAQEFQAEBBScEBwEPCwsDCg0hIhIBBQEKBAENBhMIAQkCCodgAw8DCZo/iwyEQgEFK4RVA4hiBo5xgSUHg36XYIEpjj8WKYRUgU4 X-IPAS-Result: AngBAHt57VEmacjlnGdsb2JhbABbgztQrhCSIoEOHg4BAQEBAQYNCQkUKIIkAQEFQAEBBScEBwEPCwsDCg0hIhIBBQEKBAENBhMIAQkCCodgAw8DCZo/iwyEQgEFK4RVA4hiBo5xgSUHg36XYIEpjj8WKYRUgU4 X-IronPort-AV: E=Sophos;i="4.89,720,1367964000"; d="scan'208";a="21932696" Received: from mx5.janestreet.com (HELO tot-dmz-mxout1.janestreet.com) ([38.105.200.229]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jul 2013 20:30:49 +0200 Received: from tot-oib-smtp1.delacy.com ([172.27.22.15] helo=tot-smtp) by tot-dmz-mxout1.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1V1Ksg-0006pn-Li for caml-list@inria.fr; Mon, 22 Jul 2013 14:30:46 -0400 Received: from tot-dmz-mxgoog1.delacy.com ([172.27.224.14] helo=mxgoog2.janestreet.com) by tot-smtp with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V1Ksd-0006Fb-JY for caml-list@inria.fr; Mon, 22 Jul 2013 14:30:43 -0400 Received: from mail-ea0-f180.google.com ([209.85.215.180]) by mxgoog2.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1V1Ksd-0007ls-Du for caml-list@inria.fr; Mon, 22 Jul 2013 14:30:43 -0400 Received: by mail-ea0-f180.google.com with SMTP id k10so4088332eaj.11 for ; Mon, 22 Jul 2013 11:30:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eFlKejWYoPUgzHlfRhs6S0mW5XluaVhFmrUqIS3Jge4=; b=zOmKMh+I1FurTrqwnCk2gFZU+itS/iwQ/zj75xOhPC40Bm44qWI31evWHP19HorIXS 2bKPsyhIDBRrTN24VrElzxrSVbYPgZubHVEhQV1EuojtXqNANmnnh2ADWQpRP5/Crr4p q2LjBxNH4oU5R8IpYjfLEPpi9B5C1IJStqqkQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=eFlKejWYoPUgzHlfRhs6S0mW5XluaVhFmrUqIS3Jge4=; b=nyit43uJb+8EufwqXq6dsPzwGmUsh+n1VWxsau2j0LZj7h1J7uAMUsQPUw3m6sISTT hlizbPXEl9hvx9hbi5bZKfCHQBVT/zfNjNxIl+uCvAyNP820kGRJaR9dYUTiOtg8I4lS LyQZxusaACMBnjVHKgp8vTqvXW3Vv2P0UWpbnQU91ihRvZUwSG9UIjv69OjkBz4qGcx2 eYROKlLXFTQEqefpQ7GXdiIdo9wVQ2/aHobqLRxDcetSmRuxCwapUNlzfBf6CppdUr/7 dr4IHsRAX0zt/sbLP/qAuxEyjwOvBhAYE04zidulpgxCjqWd9aQDLPhBrohTbsRPn17o rpWQ== X-Received: by 10.15.33.132 with SMTP id c4mr29310877eev.12.1374517842844; Mon, 22 Jul 2013 11:30:42 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.15.33.132 with SMTP id c4mr29310869eev.12.1374517842753; Mon, 22 Jul 2013 11:30:42 -0700 (PDT) Received: by 10.223.43.65 with HTTP; Mon, 22 Jul 2013 11:30:42 -0700 (PDT) In-Reply-To: References: <383739793.214096184.1374254520546.JavaMail.root@zimbra27-e5.priv.proxad.net> <7b4c87b5d9aa76728e239f0a2172b795.squirrel@gps.dynxs.de> <6796313D-9F02-4C70-87D9-8DC9BC896028@recoil.org> Date: Mon, 22 Jul 2013 14:30:42 -0400 Message-ID: From: Yaron Minsky To: Gerd Stolpmann Cc: Anil Madhavapeddy , r.3@libertysurf.fr, "caml-list@inria.fr" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkCB/JBFloZlLLARkLDndNysGhdZRftIp/ed3K+PCamjFPW81AyrOoPwgu6dLrq21A3GufyWe2uPn261Hs/AQCTg/dCcvOg2N6K039KmC05A+8GNWAv0EQw0cdgUQ4+2NPMwxmMn5m6UGrm4JzoRh2wffn3BQ== Subject: Re: [Caml-list] opam and godi Sigh. I don't mean to get into a fight. And the problems I've run into with GODI, though, had nothing to do with the Core packages, so that seems a bit off topic. GODI surely has its uses, and in particular the Windows support is a nice thing that OPAM still lacks. That said, I very much prefer OPAM (for the reasons echoed by others), and there's little doubt in my mind as to which package manager I recommend to people who are working on a UNIX or Mac platform. y On Mon, Jul 22, 2013 at 8:55 AM, Gerd Stolpmann wrote: > Sad to read such FUD here. The truth is that the company Yaron is working > for never managed to create good Core packages. I don't know what the > reason is, but I guess so it is within this company, since other people > with fewer resources mastered similar tasks well. This is something I was > always puzzled about, since initially there was good cooperation with this > company. > > So far I've removed Core from GODI because it misses QA standards, and > have no plans to add it again. > > Gerd > > Yaron Minsky wrote: >> While I appreciate the work that Gerd has done on GODI, I do think >> that OPAM is a significant improvement over GODI. >> >> From an end-user-experience perspective, I've found OPAM to be >> considerably smoother than GODI. In addition to having what I >> consider to be a better user interface, upgrading of packages in OPAM >> has been very smooth overall. I found upgrades in GODI to be pretty >> tricky, with many upgrades ending in failure for one reason or >> another. I suspect this has something to do with the system for >> handling of dependencies in OPAM, which has taken quite a bit of work >> to get right from what I understand. >> >> In addition, the ability to easily handle multiple compilers in OPAM >> is also a big win, from my perspective. I think it makes it much >> easier to try out and give feedback on upcoming compiler versions, >> which is good for the community as a whole. (Plus, trying out >> bleeding-edge compiler patches is fun...) >> >> With the arrival of OPAM, for the first time I feel good about >> recommending that new users try out libraries with significant >> dependencies like Core, since installing such libraries is now really >> quite simple. >> >> y >> >> On Sun, Jul 21, 2013 at 10:20 AM, Anil Madhavapeddy >> wrote: >>> On 21 Jul 2013, at 14:54, "Gerd Stolpmann" >>> wrote: >>>> >>>>> Hello, >>>>> could someone explain please the relation between godi and opam ? Is >>>>> it >>>>> concurrent ? >>>>> Godi has been there for some time, and works quite nicely. So what are >>>>> differences ? >>>> >>>> Hi, >>>> >>>> both are independent projects. OPAM is a younger project, and I don't >>>> really know what the motivation behind it is (in addition to the >>>> generic >>>> motication to hack something). There were initially claims to make it >>>> is >>>> easier to package software up, but what I've seen is actually not much >>>> different from GODI (actually even worse now that GODI allows it to >>>> fully >>>> automate package releases). >>> >>> The answer's right there on the front page: >>> >>> "OPAM is a source-based package manager for OCaml. It supports multiple >>> simultaneous compiler installations, flexible package constraints, and a >>> Git-friendly development workflow." >>> >>>> The feature sets are not the same, and some stuff works better in OPAM >>>> and >>>> some in GODI. As I'm advocating the latter, let me point out some >>>> features >>>> where I think GODI is better: >>> >>> Feature minutiae aside, I'd say the biggest benefit of OPAM is the more >>> open development workflow. It's easier for people to maintain their >>> own branches and contribute changes to the central repository. >>> >>> Let's look at the stable repository "pulse": >>> https://github.com/OCamlPro/opam-repository/pulse/monthly >>> >>> It tells us that in the last month, there have been 30 authors that have >>> pushed 167 package updates. These have all come in as pull requests that >>> can still be browsed. For example, see the latest Core from Jane >>> Street: >>> https://github.com/OCamlPro/opam-repository/pulls?state=closed >>> >>> Several development groups also maintain their own remotes without any >>> need to depend on the central repository. For example, see Citrix's: >>> https://github.com/xapi-project/opam-repo-dev/tree/master/packages >>> >>> As Gerd points out, GODI is an older and more mature project. I find >>> OPAM more useful for my own personal development workflow though. You >>> should try both out and see which one you prefer. >>> >>> cheers, >>> Anil >>> >>> -- >>> Caml-list mailing list. Subscription management and archives: >>> https://sympa.inria.fr/sympa/arc/caml-list >>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >>> Bug reports: http://caml.inria.fr/bin/caml-bugs >> >> -- >> Caml-list mailing list. Subscription management and archives: >> https://sympa.inria.fr/sympa/arc/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs >> >> > > > -- > Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de > Creator of GODI and camlcity.org. > Contact details: http://www.camlcity.org/contact.html > Company homepage: http://www.gerd-stolpmann.de > *** Searching for new projects! Need consulting for system > *** programming in Ocaml? Gerd Stolpmann can help you. >