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 5E2557F16D for ; Tue, 1 Sep 2015 17:06:53 +0200 (CEST) IronPort-PHdr: 9a23:/f+3Hh26Gm24HKs4smDT+DRfVm0co7zxezQtwd8ZsegRL/ad9pjvdHbS+e9qxAeQG96Lt7Qc06GL6OjJYi8p39WoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6kO74TNaIBjjLw09fr2zQd6OyZzvnL3ps7ToICx2xxOFKYtoKxu3qQiD/uI3uqBFbpgL9x3Sv3FTcP5Xz247bXianhL7+9vitMU7q3cYk7sb+sVBSaT3ebgjBfwdVWx+cjN92Mq+jgVCVQuG4HYrfWERlBZVS1ze8BziXr/+tiz8uvc73iSGa57YV7cxDB2k7qMjbRbkiC4ZPiY0/G3Gwph5iqNfiAisrBt+x8jTeo7DZ6k2Rb/UYd5PHTkJZc1WTSEUR9rkN4Y= Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=anil@recoil.org; spf=None smtp.mailfrom=anil@recoil.org; spf=None smtp.helo=postmaster@bark.recoil.org Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of anil@recoil.org) identity=pra; client-ip=5.153.225.51; 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=5.153.225.51; 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@bark.recoil.org) identity=helo; client-ip=5.153.225.51; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="anil@recoil.org"; x-sender="postmaster@bark.recoil.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CJBQCmvuVV/zPhmQVdgxtUEwNTgyO7CwEJgXeCQ4M4AgiBNTgUAQEBAQEBAQGBCYIdggYBAQEDASNWEAsYAgImAgJJAQ0GExSIEgwJtDOVCQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSKHYoFngQWEWDMHMYI4L4EUBZVBhQeCbYUBT4gpkXQmgg8cgVVwgk0BAQE X-IPAS-Result: A0CJBQCmvuVV/zPhmQVdgxtUEwNTgyO7CwEJgXeCQ4M4AgiBNTgUAQEBAQEBAQGBCYIdggYBAQEDASNWEAsYAgImAgJJAQ0GExSIEgwJtDOVCQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSKHYoFngQWEWDMHMYI4L4EUBZVBhQeCbYUBT4gpkXQmgg8cgVVwgk0BAQE X-IronPort-AV: E=Sophos;i="5.17,449,1437429600"; d="scan'208";a="175623200" Received: from bark.recoil.org ([5.153.225.51]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Sep 2015 17:06:52 +0200 Received: from [10.12.0.104] (no-dns-yet.convergencegroup.co.uk [37.205.61.206]) by bark.recoil.org (OpenSMTPD) with ESMTPSA id 67fb4c66 TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Tue, 1 Sep 2015 16:06:50 +0100 (BST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Anil Madhavapeddy In-Reply-To: <55E48E3C.4090202@glondu.net> Date: Tue, 1 Sep 2015 16:06:51 +0100 Cc: caml-list@inria.fr Content-Transfer-Encoding: quoted-printable Message-Id: <33BFDA1B-3336-42CE-B279-28F8C2DC3D14@recoil.org> References: <1C02B1E2-D17D-4008-998E-B17048C62DFA@gmail.com> <55E47B7E.6050901@glondu.net> <55E47D5A.6080806@inria.fr> <55E48E3C.4090202@glondu.net> To: =?utf-8?Q?St=C3=A9phane_Glondu?= X-Mailer: Apple Mail (2.2104) Subject: Re: [Caml-list] We need a rich standard library distributed with OCaml, really On 31 Aug 2015, at 18:26, St=C3=A9phane Glondu wrote: >=20 > Le 31/08/2015 18:14, Francois Berenger a =C3=A9crit : >>>> Depending on external libraries used to be a problem when there was no >>>> consensus on OCaml packaging (no longer than a few years ago people >>>> where reluctant to even use ocamlfind). We now have a reasonable >>>> consensus on a packaging story, and installing third-party libraries >>>> has never been as easy as it is today -- except on Windows, meh. >>>> I think you should embrace the idea of depending on software outside >>>> the OCaml distribution. >>>=20 >>> Depending on a multitude of external libraries makes packaging more >>> difficult. I am talking about "system" packaging (deb, rpm...) here, not >>> OPAM. And "install OPAM first" is not a very satisfactory way of >>> installing some software written in OCaml in a stable environment. >>=20 >> Why not? >=20 > Packages in OPAM do not benefit from QA done in e.g. Debian or Fedora. >=20 > Besides, a regular Debian user (for example) is used to Debian policies, > not OPAM ones. Don't assume that anyone wanting to use software written > in OCaml is part of the OCaml community. I am happy as a Debian user to > not have to deal with CPAN / CTAN / PyPI / whatever. The opposite also holds true -- OPAM remains relatively consistent across operating system distributions, in an age when students are bringing their own laptops running various strands of Linux, *BSD and MacOS X. Only Windows languishes behind at the moment. Our experience in Cambridge is that our sys-admins have had no problem installing OPAM on our centrally managed (Ubuntu LTS) lab machines, while students followed the online instructions to get it running on their own flavours. Windows students run a Vagrant or Virtualbox VM, or can soon use Boot2Docker. My view on packaging is that it ultimately needs to be automated from a central metadata source held in the package, with only OS-specific concerns being put into the upstream port. Right now, individual distributions go to great pains to separately calculate packing lists for (e.g.) native vs bytecode, where this should all really be information provided by a standardised build system. That's the intention of various efforts such as OASIS, oasis2opam, and the early efforts to get opam2deb and opam2rpm working: https://github.com/ocaml/opam/wiki/opam2%7Brpm,deb%7D The OPAM `depext` mechanism also tracks external OS packaging metadata in order to do a better job of continuous integration. Don't get me wrong -- I have a huge respect for the efforts poured into Debian and Fedora packaging of individual libraries, and I also spend significant time myself maintaining OpenBSD ports of OCaml libraries. But I also appreciate being able to get the latest libraries and manipulate them at a source-code level much more easily via OPAM. These are all complementary efforts :-) >> In my experience, opam installs are quite reproducible. >=20 > In my experience, they are not... Any specific concerns here? We run quite a bit of automated testing on the OPAM repository, and the only real source of non-reproducibility in a well-controlled base environment (as found when running in a Linux container or BSD VM) is if the external aspcud package solver is changed. >=20 >> You can even specify the version number you want to install. >=20 > ... but I've never tried that. Aren't old versions of packages removed > at some point? No, old versions are never deleted from the OPAM repository and remain available to install. >=20 >> [...] opam install things in a user's home >> directory, which is not what you want for a system-wise installation of >> a software/library. >=20 > AFAICT, opam only "trusts" packages to install things in a user's home. The build is also never run as root, only as the user uid that invoked OPAM. The `OPAMROOT` variable can be set to a system-wide area if desired. See `opam --help` for a full list. regards, Anil