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 BEDE15D5 for ; Mon, 24 Dec 2018 21:11:08 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.56,393,1539640800"; d="scan'208,217";a="361691479" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 24 Dec 2018 22:11:07 +0100 Received: by sympa.inria.fr (Postfix, from userid 20132) id 812FC82566; Mon, 24 Dec 2018 22:11:07 +0100 (CET) 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 AA8E6822B8 for ; Mon, 24 Dec 2018 22:10:58 +0100 (CET) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=kennethadammiller@gmail.com; spf=Pass smtp.mailfrom=kennethadammiller@gmail.com; spf=None smtp.helo=postmaster@mail-it1-f173.google.com IronPort-PHdr: =?us-ascii?q?9a23=3AfZ8bIB0mLFQMqiz0smDT+DRfVm0co7zxezQtwd8Z?= =?us-ascii?q?se0QLfad9pjvdHbS+e9qxAeQG9mDu7Qc06L/iOPJYSQ4+5GPsXQPItRndiQuro?= =?us-ascii?q?EopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBgvwNRZv?= =?us-ascii?q?JuTyB4Xek9m72/q99pHPYAhEniaxba9vJxiqsAvdsdUbj5F/Iagr0BvJpXVIe+?= =?us-ascii?q?VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PGAv5c3krgfM?= =?us-ascii?q?QA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7S60/Vza/4KdxUBLnhy?= =?us-ascii?q?cJOTA6/m/KlMJ/kLlWrwi9qxFl2YPYfJ2ZOfh4c6jAfd0aX21BXsNJWiJEHIy8?= =?us-ascii?q?aY0PAPQdPeZYsoLwu0YBogG7BQKxA+3vyztIhnvo0q0gzu8sFgLG0xImH9IIrn?= =?us-ascii?q?vUsNX1O70PXu+vyanIyDTDb/dS2Tjj8ojFaR8hofSWUrJxdcrd01UgFwTAjliJ?= =?us-ascii?q?r4HuIjCb1vwVvmSF8+ZtUfijhm0npg1rvzSix8YhhpPUio8XxF3J8zhyzpwvKt?= =?us-ascii?q?2iUkF7ZMapEJtOuCGeMIt7WsYiTHtpuCY+07EGuIK7cDUTxJQp2hLSafKKf5KH?= =?us-ascii?q?4hLkU+aRLjN4i2x/dL2jgBay9FCsyuz6VsaqzFZHtjRJnsXIu3wX1BHe6tKLRu?= =?us-ascii?q?Z880qgwzqDygLe5+9cLUAxj6XbKpohwrAqlpoUtETOBiz2l1vwjK+QaEok5uio?= =?us-ascii?q?5P76bbr8o5+cMo50igX6MqswgMyyGus4Mg0UUGia/eSwzqHs/Ur8QLlSlP05jr?= =?us-ascii?q?HZsIzGJcQcvqO2HxVa0oMn6xqmCzem0c8YnWUcIVJeeBOHipDpNEvULPD5C/e/?= =?us-ascii?q?mVWsny1xy/DIJL2ySqnKe3PKlbOpYK1w8VUUnAE6yNQa45NPFpkAJujyUwn/ro?= =?us-ascii?q?qLIAU+NlmXzuDhBcl9nqoSUGfHJ66dNK7I+QuL6+QpLvWMbYMcvTP8L/wo/dbh?= =?us-ascii?q?iHY4nRkWeqz/jshfU2yxAvkzexbRWnHrmNpUST5b7Dp7d/TjjRi5aRAWYn+zW6?= =?us-ascii?q?wm4TRiUdCpCI7CQsamh7nThX7nTK0TXXhPDxW3KVmtb5+NAq5eZyebI8snmTsB?= =?us-ascii?q?B+D4Ft0RkCq2vQq/8IJJa+rZ/ipC68Dm3dlxouzPzFQ8rGMvScua1G6JQid/mW?= =?us-ascii?q?ZaHzI=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUBQDwSiFcgK2mVdFig20FghEng36BH?= =?us-ascii?q?YJekBeLN2+PRQ0Fh10aBwEENBIBAwEBAgEBAQEBEwEBCQ0JCCclDII6IoMYHQE?= =?us-ascii?q?bHgMSEDcCJAERAQUBIoUeAQMVmDWDHzyLGYESBQEXgncFhC4KGScNXoE3AgYSj?= =?us-ascii?q?C0XgX+DdgGBVBkBhkeCVwKJfIZnkGgJgWqPfxiBYJAGil+POw8hgTyBdzMaI4E?= =?us-ascii?q?BgjuCJwwLfwEJgkGKcSQwj0oBAQ?= X-IPAS-Result: =?us-ascii?q?A0AUBQDwSiFcgK2mVdFig20FghEng36BHYJekBeLN2+PRQ0?= =?us-ascii?q?Fh10aBwEENBIBAwEBAgEBAQEBEwEBCQ0JCCclDII6IoMYHQEbHgMSEDcCJAERA?= =?us-ascii?q?QUBIoUeAQMVmDWDHzyLGYESBQEXgncFhC4KGScNXoE3AgYSjC0XgX+DdgGBVBk?= =?us-ascii?q?BhkeCVwKJfIZnkGgJgWqPfxiBYJAGil+POw8hgTyBdzMaI4EBgjuCJwwLfwEJg?= =?us-ascii?q?kGKcSQwj0oBAQ?= X-IronPort-AV: E=Sophos;i="5.56,393,1539640800"; d="scan'208,217";a="361691424" Received: from mail-it1-f173.google.com ([209.85.166.173]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 24 Dec 2018 22:10:57 +0100 Received: by mail-it1-f173.google.com with SMTP id g85so16948528ita.3 for ; Mon, 24 Dec 2018 13:10:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=kXIK7O1h+6fDwR51dC1/GUBigRDYjZI2pmfn60qAZXk=; b=pYlj7pWTJHl9UWQX3pwzgWtpajACPxIBwUfjrJ7IFxcnbUyepAKoZ1XqfTcJyi/3Ol yaiiefIQufz1eKb+gi0d5S4A1mMetVdNMfiNBAsZoFKD8hBqSZ0HE6QaY93DifiiIUM3 51fwV5ZFfmUpzX4Laaw/GYVOtyVtZF7sir8+GU0T0I4aD/Eo48v1cligf4+c7ivmLyEC QMeThMnwHeiPQs0w/PfrMOwThhdGPoBVXlcG4X4vGqvS3jSH4bKcY9iGG26zj37Uu5MA W2GBEsjIrgMD8ccjFaEISEjppBfAxvkbOkizBllw8didGVrr3muO2OaVr/Xo9kE7UmMs CiBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kXIK7O1h+6fDwR51dC1/GUBigRDYjZI2pmfn60qAZXk=; b=Ci0fw74/M2VQEnUVvnFkbUs80XSeytvtvFc/cIAaqRwi6Jm7W9rgBwz+kgFYB5Ko5e 8Qtlt0v/Uz7KwsEPKpcRAYUNRGxhcN/ToeIqDwNKO3p/47yS2chfz80iOT7eL/17WF6Q 06Uj92SuQ6IvzvQtu5h3VHgQY1xquZdGiLFotrQ1OP5wdsl8aI/l+9qIcWhN+wPXRfb/ mnXkRqQRCH5lSRUbqxUblADigcOL0x2u6u1JPrK6EBq7PZysWdqFnQ95OEG8J2GVHHCJ AeLwo5SSCnXMGm0KNYJQdS3n0e+C+uhZ2dc9HHZJ+vrKSN4mlSFJE2eslLRrecW/FH0b F/HA== X-Gm-Message-State: AJcUukdBDb341TFJV5vkYQqCBs56fvNgrcRI4olykdAudkc2CXCbpr4P 9kwYyRHKHynBKtqEQGVY8XHi8IrGOpcJ42wp9rI3NA== X-Google-Smtp-Source: ALg8bN6nA89utpm9aIJxc6GLbqxTN2gQvqOukL51tyxS3PLdoX5PEY1d4gjtVRFKUSoOl75KCc1lQGo8m/mRIb4E2s0= X-Received: by 2002:a24:7fc3:: with SMTP id r186mr9132359itc.178.1545685855670; Mon, 24 Dec 2018 13:10:55 -0800 (PST) MIME-Version: 1.0 From: Kenneth Adam Miller Date: Mon, 24 Dec 2018 16:10:44 -0500 Message-ID: To: caml users Content-Type: multipart/alternative; boundary="0000000000005c9a9e057dcb0853" Subject: [Caml-list] Opam improvement request Reply-To: Kenneth Adam Miller X-Loop: caml-list@inria.fr X-Sequence: 17264 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: --0000000000005c9a9e057dcb0853 Content-Type: text/plain; charset="UTF-8" I'm not sure if opam already does this, and I'm not unhappy with opam at all about it, but I'd like to be able to have installation or upgrade commands have fast rollback/forward capability. Let me explain what I mean. So far as I've seen or know about, if an install fails then opam will give a file that describes the state it had and which you can execute using a command it also gives. I'm too lazy to look that up, but that's a different functionality than what I'm describing - and more importantly, it represents part of the problem because it requires building all of the packages from source and because it itself suffers from the fragility that I'm trying to get around. What I'd like is, if opam could quickly snap back and forth between combinations of package versions. I don't want to manage specification files, I'd kind of like a docker like interface where I could just put notes by dated, named package selection options and have a command manage it for me. I don't want to track files manually. I've had some scenarios where opam tells me how to restore my state, after attempting to do an install or upgrade but in the process had an error. What has actually happened then was, I had had a working version of packages, which then broke or went away on the possibility of some version change. opam packages can change rather quickly too, so I remember I once just had to quit and come back, and doing an opam update got the changes to take successfully because someone pushed a change that fixed it. It would nice if, if there are any errors, I could keep my old state without even having to re-install that. And that's because I don't care if I have even 20 times as much space consumed by opam because opam is keeping old states. I just want to always have some working system. I hope it doesn't sound like I'm complaining or being negative. All I'm saying is I don't want to have some dependency version mismatch cause the current system to become inoperable, and I know that opam can maintain multiple compilers and all of that, and that there are other levels where I could apply this, even using docker I can entirely get rid of it. But if opam were to use snapshotting as the default behavior and exchanging snapshots merely meant swapping out folder names within the opam directory, that would be really fantastic. Often, doing an update or upgrade means that all the packages that depend on it have to get rebuilt. OCaml is fantastic for having such a fast build time, but this still takes hours if you have large dependencies. Again, opam packages change all the time, and if you don't regularly stay up to date, it's really easy to get downwind of drastic changes; leaping many versions for a given package can trigger the kinds of unexpected breaks that I'm talking about. It makes sense to me to think of opam package installs as being in a kind of git staging area, where I can consider them tentatively and test it against a particular package, but easily and quickly revert back to other built packages (without needing to rebuild something again unnecessarily) that I know are working. -- 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 --0000000000005c9a9e057dcb0853 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not sure if opam already does this, and I'm no= t unhappy with opam at all about it, but I'd like to be able to have in= stallation or upgrade commands have fast rollback/forward capability. Let m= e explain what I mean.

So far as I've seen or know a= bout, if an install fails then opam will give a file that describes the sta= te it had and which you can execute using a command it also gives. I'm = too lazy to look that up, but that's a different functionality than wha= t I'm describing - and more importantly, it represents part of the prob= lem because it requires building all of the packages from source and becaus= e it itself suffers from the fragility that I'm trying to get around.

What I'd like is, if opam could quickly snap ba= ck and forth between combinations of package versions. I don't want to = manage specification files, I'd kind of like a docker like interface wh= ere I could just put notes by dated, named package selection options and ha= ve a command manage it for me. I don't want to track files manually.

I've had some scenarios where opam tells me how = to restore my state, after attempting to do an install or upgrade but in th= e process had an error. What has actually happened then was, I had had a wo= rking version of packages, which then broke or went away on the possibility= of some version change. opam packages can change rather quickly too, so I = remember I once just had to quit and come back, and doing an opam update go= t the changes to take successfully because someone pushed a change that fix= ed it. It would nice if, if there are any errors, I could keep my old state= without even having to re-install that. And that's because I don't= care if I have even 20 times as much space consumed by opam because opam i= s keeping old states. I just want to always have some working system.
<= br>I hope it doesn't sound like I'm complaining or being negative. = All I'm saying is I don't want to have some dependency version mism= atch cause the current system to become inoperable, and I know that opam ca= n maintain multiple compilers and all of that, and that there are other lev= els where I could apply this, even using docker I can entirely get rid of i= t. But if opam were to use snapshotting as the default behavior and exchang= ing snapshots merely meant swapping out folder names within the opam direct= ory, that would be really fantastic.=C2=A0

Often, doing an update or= upgrade means that all the packages that depend on it have to get rebuilt.= OCaml is fantastic for having such a fast build time, but this still takes= hours if you have large dependencies. Again, opam packages change all the = time, and if you don't regularly stay up to date, it's really easy = to get downwind of drastic changes; leaping many versions for a given packa= ge can trigger the kinds of unexpected breaks that I'm talking about.= =C2=A0

It makes sense to me to think of opam packa= ge installs as being in a kind of git staging area, where I can consider th= em tentatively and test it against a particular package, but easily and qui= ckly revert back to other built packages (without needing to rebuild someth= ing again unnecessarily) that I know are working.=C2=A0
--0000000000005c9a9e057dcb0853--