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