From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by c5ff346549e7 (Postfix) with ESMTPS id 3E5C95D5 for ; Fri, 30 Nov 2018 16:01:37 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.56,299,1539640800"; d="asc'?scan'208";a="358196582" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 30 Nov 2018 17:01:25 +0100 Received: by sympa.inria.fr (Postfix, from userid 20132) id 70A968255D; Fri, 30 Nov 2018 17:01:25 +0100 (CET) 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 8DD99824CF for ; Fri, 30 Nov 2018 16:23:30 +0100 (CET) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=louis.gesbert@ocamlpro.com; spf=PermError smtp.mailfrom=louis.gesbert@ocamlpro.com; spf=Pass smtp.helo=postmaster@mail.antislash.info IronPort-PHdr: =?us-ascii?q?9a23=3AXaEJpR+b/+XlNv9uRHKM819IXTAuvvDOBiVQ1KB3?= =?us-ascii?q?1u8cTK2v8tzYMVDF4r011RmVBdWds6oMotGVmpioYXYH75eFvSJKW713fDhBt/?= =?us-ascii?q?8rmRc9CtWOE0zxIa2iRSU7GMNfSA0tpCnjYgBaF8nkelLdvGC54yIMFRXjLwp1?= =?us-ascii?q?Ifn+FpLPg8it2O2+557ebx9UiDahfLh/MAi4oQLNu8cMnIBsMLwxyhzHontJf+?= =?us-ascii?q?RZ22ZlLk+Nkhj/+8m94odt/zxftPw9+cFAV776f7kjQrxDEDsmKWE169b1uhTF?= =?us-ascii?q?UACC+2ETUmQSkhpPHgjF8BT3VYr/vyfmquZw3jSRMNboRr4oRzut86ZrSAfpiC?= =?us-ascii?q?gZMT457HrXgdF0gK5CvR6tuwBzz4vSbYqINvRxY7ndcMsaS2RfQ8hfWS9PAoS+?= =?us-ascii?q?YIsBAOUOIf1Vr4bhq1YUtxayGRWgCeHpxzRVhnH2x6o60+E5HA/A2wwgAtMOsG?= =?us-ascii?q?/Jp9v0KqgSSvu6w7fSzTXfcvhb3jP96I/VchAguvGAR71wftTKyUY0CQzFlEmQ?= =?us-ascii?q?pJfiPzyJzOsNtmyb7/J6VeKokWIotwZxoj22y8oql4LHiIUVylXe+iV4xoY4Pd?= =?us-ascii?q?q4R1Jhbt6hFJtcrSaaN5F5Qs86QmFovjw6yrwctpKhcigK0owrxxHea/ybc4iI?= =?us-ascii?q?/wnsWPyNLjd/gXJofq+0iRWq8UW4xODxVNO43EtJoydHiNXAqH8A2hPJ5sWJS/?= =?us-ascii?q?Zw+Fqq1yyV2ADJ8O5EJFg5larFJJ4lxb49jp8Tvl7CHi/ygkn5lqmWdlkl+uiz?= =?us-ascii?q?7+ToeK7mpp+GO491jAH+PKMultS+AeQ+LAcOQ3CW9Oq+2bH54EH0Q7dHguconq?= =?us-ascii?q?TWv53WP8oWq6+hDw9QyIkj6hK/Dzm80NQfmHkKNFZFeBWaj4joIFHCOv/4Aumk?= =?us-ascii?q?g1u3jjhr3ezGM6bmAprRNHfDlbPhfa5n605b0gY80ddf55dMBrEbPP3zQlPxtM?= =?us-ascii?q?DfDhIhLwO72ePnCNFk2oMaWGKPGbOZPbjJsV6I4+IvO/ODaJUUuDb7Mfgl5uTh?= =?us-ascii?q?gWU3mV8HLuGV2s4mYW+xBLxPJkSfKS79i8gICyEDuws4ZOPvgVyGFzVUYiDhcb?= =?us-ascii?q?g742QfD5+nFs/sS5unjaadlHO/GYBXfSZJB0uGHG30X4KPUvIIcDiVZMRml2pX?= =?us-ascii?q?BvCaV4Y92ET250fBwL19I7+Ro3VA7MOx5J1O/+TW0CoK23lxBsWZ3XuKSjgozG?= =?us-ascii?q?QDTjoyxLp450d6zwXdiPQqs7ljDdVWoshxfEIiL5eFk759ANn3XhrbeZGCT1P0?= =?us-ascii?q?Goz7UwF0dco4xpo1W2g4G9imiUqajS+jArtTnrqXBYcw+7ncmXn3KcEvkns=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUBQDhVAFc/yT0uyVbCBwBAQEEAQEHB?= =?us-ascii?q?AEBgWWBW4EPcBIng3mId402jgqCQocQgWYIBSOBVIJ1AgiDRwcBAzQSAQMBAQI?= =?us-ascii?q?BAQEBAWwcDII2JAGCYQEBAQECASNKAQsFCwkCGAkECAEBARICAg8BRwYTGYMJg?= =?us-ascii?q?XkMC4pSm1CBL4QtARNAhSuCbYsEP4ERghRQLoMeAQEBAQKBGB0BAmQJAgWCNYJ?= =?us-ascii?q?XAokJEpZFVQcCgh4EhF2GIxuEEgqBUU2HNIRLgniCeYpmiBMvgjyBXSGBVTMaI?= =?us-ascii?q?1CCbAmDNAECgkiBPoNWhUBBMAGMAgINFQKCJwEB?= X-IPAS-Result: =?us-ascii?q?A0AUBQDhVAFc/yT0uyVbCBwBAQEEAQEHBAEBgWWBW4EPcBI?= =?us-ascii?q?ng3mId402jgqCQocQgWYIBSOBVIJ1AgiDRwcBAzQSAQMBAQIBAQEBAWwcDII2J?= =?us-ascii?q?AGCYQEBAQECASNKAQsFCwkCGAkECAEBARICAg8BRwYTGYMJgXkMC4pSm1CBL4Q?= =?us-ascii?q?tARNAhSuCbYsEP4ERghRQLoMeAQEBAQKBGB0BAmQJAgWCNYJXAokJEpZFVQcCg?= =?us-ascii?q?h4EhF2GIxuEEgqBUU2HNIRLgniCeYpmiBMvgjyBXSGBVTMaI1CCbAmDNAECgki?= =?us-ascii?q?BPoNWhUBBMAGMAgINFQKCJwEB?= X-IronPort-AV: E=Sophos;i="5.56,299,1539640800"; d="asc'?scan'208";a="287436992" Received: from antislash.info (HELO mail.antislash.info) ([37.187.244.36]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Nov 2018 16:23:25 +0100 From: Louis Gesbert To: Yawar Amin Cc: Ocaml Mailing List Date: Fri, 30 Nov 2018 16:23:11 +0100 Message-ID: <3335300.gsrt7Ya9Qa@agaric> Organization: OCamlPro In-Reply-To: References: <20181126101448.3ee5jgz4c6ulsbbr@first.in-berlin.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5768264.cA62KJnZDl"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Validation-by: louis.gesbert@ocamlpro.com Subject: Re: [Caml-list] Build-/Installation-Tools - not enogh of them? Reply-To: Louis Gesbert X-Loop: caml-list@inria.fr X-Sequence: 17195 Errors-to: caml-list-owner@inria.fr Precedence: list Precedence: bulk Sender: caml-list-request@inria.fr X-no-archive: yes List-Id: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --nextPart5768264.cA62KJnZDl Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Thanks all for this input. While working on the intrinsics and details of t= he tools, it's easy to lose the big picture, and the very important point o= f view of the newcomers. So first, as the main developper of opam 2.0, I'd like to say that we have = been putting a lot of work in it, and a large part of the effort was to imp= rove for convenience, and the many use-cases that weren't supported before = =E2=80=94 including, but not limited to, reproducible build environments, a= nd project-local sandboxes, a.k.a. switches. The documentation, however, is severly lacking at the moment on all these n= ew features, and the preferred and simplest ways to accomplish all the basi= c tasks. For all asking about the detailed formats, we have a fairly comple= te manual [1], and the API should be fairly well documented [2], but indeed= , it's way too detailed to be the first documentation you would get to. Let me assure you however that everything is slowly getting into place for = an easier approach for everyone. I'll go below through the "typical workflo= w" you propose, checking what is here or not, but let's first focus on the = users rather than the developers: =2D installing ocaml: indeed, if not easily available for your system, the easiest is to instal= l opam, then just run `opam init`. (Yes, we should be explicit in the doc t= hat _this_ is the command that will install the compiler) =2D installing a given package, and assuming opam is installed and initiali= sed: * if in the repository, just one `opam install` command should be all yo= u need * otherwise, if your source is available somewhere and contains an opam = package definition file, `opam pin URL` is everything you need (URL pointin= g to an archive, or a git repository, etc.). We could merge this use-case i= nto `opam install` for better discoverability. * if not and/or you want to build the project manually from a clone, the= support has been much improved in opam 2, so that you can for example docu= ment specific pinned dependencies, or a "locked" development state (see opa= m-lock [3] to do that automatically). Then e.g. `opam switch create . --loc= ked` will recreate a local switch with the exact same development configura= tion, and install the project in it. `opam install . --locked` also works, = if you don't want the local sandbox. =2D it has been mentionned already in this thread, but the `opam bundle` pl= ugin can make distribution easier by including the whole OCaml + opam + pac= kage environment in a single, self-building self-extracting archive. At the= cost of rebuilding everything on installation. A new release is pending [4= ]. Yes, it's yet another tool, but with its straight-forward interface and = everyting explained in its 100-lines, included manpage, I find the criticis= m uncalled for. Not a silver bullet by any means, but it fits some use-case= s. As for using wrapping Makefiles, they are nice for simple build-system call= s, and I like them if only to document the entry-point, but shouldn't IMHO = mess with the packaging system. Note also that the main purpose of `opam` f= iles is actually to document the building commands of any project, taking i= nto account all OS specificities, and in an easily understandable format. I= personally find that having clear and simple build instructions arout the = top of the README is enough. Once properly documented from the opam side (huh), I expect project maintai= ners to be able to put simple setup + installation instructions at the top = of their READMEs, so that users who don't care about OCaml or opam just nee= d to copy-paste them to get the environment setup and the project compiled.= As far as I understand it now, this is where the problem really stands. To= avoid having to look anything up or learning about exotic build system, th= is is the best compromise IMHO. I'd also like to point out that this is not specific to OCaml, and I believ= e all language package managers / build systems suffer from these issues: I= for one struggle every time I have to use something building with NPM, and= they don't generally provide Makefiles. Of course, with a tool as popular = as NPM, the problem is less visible because you have to go through it anywa= y. So we do need to improve documentation and simplify basic workflows as m= uch as possible, but expecting people to work with OCaml without learning a= ny of the tooling is unrealistic (unless they stick to an online IDE or e.g= =2E Learn-OCaml, and even that is tooling in some form). Let me now go through your "typical workflow": =2D-- > cd some-ocaml-proj > opam install # Switches compiler if necessary and installs and locally > caches package dependencies You can do this with `opam switch create .` Since "if necessary" is pretty subjective, just run `opam install .` if you= prefer to share the environment with other projects. > opam build `opam install .` > opam run # Automatically builds if necessary there is no package=E2=86=90=E2=86=92executable bijection, so I don't see h= ow this would work? (same as for OS-level packages) see below, but this might be `dune exec ` > opam test # Ditto indeed here we enter the domain where the separation between build system a= nd packaging system can hurt. You can run `opam install . --with-test`, but= probably want `dune runtest` instead. > opam package # Ditto; --upload option can immediately upload to opam at this point you must already have a package definition available ? Or do = you mean creating a release archive ? If your source is hosted on Github, you only need to push a tag and run `op= am publish` (you otherwise need to provide an URL for the source archive an= d that's it). > opam doc # Builds documentation with ocamldoc or whatever > opam login -u user -p password I am not sure what you have in mind here. `opam publish` will go through Oa= uth authentification with Github for submitting your new package. =2D-- As one last note, let me mention that we are right now discussing: =2D better integration of opam and dune =2D integration of system dependency handling ("depexts") into opam Hope this helps, feedback and questions welcome. Louis Gesbert =E2=80=94 OCamlPro [1] https://opam.ocaml.org/doc/Manual.html [2] https://opam.ocaml.org/doc/api/index.html [3] https://github.com/AltGr/opam-lock [4] https://github.com/ocaml/opam-repository/pull/13064 > - Yawar Amin, 26/11/2018 11:41 - > If anyone would like to chime in and say that OCaml build and packaging > system is not that complicated, I would recommend first looking at > https://github.com/rizo/awesome-ocaml#package-management . IMHO we need to > seriously look at consolidating efforts around OPAM for package managemen= t, > packaging, building, testing and running. All the serious language-specif= ic > package managers do it, it's a proven strategy and it simplifies life for > the developer. >=20 > This could be a typical workflow: >=20 > cd some-ocaml-proj > opam install # Switches compiler if necessary and installs and locally > caches package dependencies > opam build > opam run # Automatically builds if necessary > opam test # Ditto > opam package # Ditto; --upload option can immediately upload to opam > opam doc # Builds documentation with ocamldoc or whatever > opam login -u user -p password >=20 > Regards, >=20 > Yawar >=20 > On Mon, Nov 26, 2018 at 5:15 AM Oliver Bandel > wrote: >=20 > > Hello, > > > > a while ago it looked like there were not enough build- and > > installation-tools > > for OCaml. I remember some discussions about that. > > > > Now it seems to me that there are a lot of them. > > So, developers can pick the one they know about. > > > > For all these tools there might be good reasons to use them, and those > > developers who looked at these tools and choose them for their projects, > > will > > know them well enough. > > > > The situation differs, if one wants to package the written software, > > and one needs to know many of those tools, just to compile the stuff. > > So, when one just wants to compile and install some software, > > just for that, it would take much effort to learn the different > > build-tools. > > > > So, packaging has become more complicated, even though for the develope= rs > > these tools may save time. > > > > It would be nice if people who used one of the many new building tools > > could provide a Makefile that allows just to type > > "make" and "make install", instead of expecting everyone who wants to > > compile > > the software to first learn just-another-build-tool. > > > > Also it would be good, to mention early, which installation tools > > (make-dependencies) > > are in use, and too mention needed packages (opam or others) to just bu= ild > > the stuff. > > > > Thanks and regards, > > Oliver Bandel > > > > -- > > Caml-list mailing list. Subscription management and archives: > > https://sympa.inria.fr/sympa/arc/caml-list > > https://inbox.ocaml.org/caml-list > > Forum: https://discuss.ocaml.org/ > > Bug reports: http://caml.inria.fr/bin/caml-bugs > > >=20 >=20 --nextPart5768264.cA62KJnZDl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEbvv1DIVPNISNNdcMGDmcR4apvJgFAlwBVd8ACgkQGDmcR4ap vJgmeAf+Pjvquj/i+qxFtL2gXuNaVJag2v5EES88T5VlocmQ2DXUZhlOChJxRL+B 4rDiV3J16ZZ7EaGPlSJQnoh9tpsDs7zDv2cPfoAQx7nZv7TJYV1hduBd3iEbtGCz S6mdSnzhXHSQh1CDEOuZ/jJNXS4LsMRB+hgE+i2Mh6TGMMP+6QNQZRmfwk093bHm cXFjIfGGxCDO7QLy5aJx0o1tzOkyxcmUdIRYwdLXZEi5iBspjkwHg2y8Vch7XTuF esKR5+z9dWnyOK3chddBsXE5ZnUUfZ+JIQsr4sopIUymj/M1hiaey2FK8dX2i9cO D4UGPaura4wSDIojSlAoLFRRDfCC/A== =63aT -----END PGP SIGNATURE----- --nextPart5768264.cA62KJnZDl--