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 ESMTP id 862BC5D5 for ; Tue, 25 Dec 2018 17:43:09 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.56,397,1539640800"; d="scan'208,217";a="361758782" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 25 Dec 2018 18:43:08 +0100 Received: by sympa.inria.fr (Postfix, from userid 20132) id 2E6B182566; Tue, 25 Dec 2018 18:43:08 +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 ED278822B8 for ; Tue, 25 Dec 2018 18:42:54 +0100 (CET) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=kennethadammiller@gmail.com; spf=Pass smtp.mailfrom=kennethadammiller@gmail.com; spf=None smtp.helo=postmaster@mail-it1-f176.google.com IronPort-PHdr: =?us-ascii?q?9a23=3ARJ9g4x8+dxtqUP9uRHKM819IXTAuvvDOBiVQ1KB3?= =?us-ascii?q?0OgcTK2v8tzYMVDF4r011RmVBdWds6oMotGVmpioYXYH75eFvSJKW713fDhBt/?= =?us-ascii?q?8rmRc9CtWOE0zxIa2iRSU7GMNfSA0tpCnjYgBaF8nkelLdvGC54yIMFRXjLwp1?= =?us-ascii?q?Ifn+FpLPg8it2O2+557ebx9UiDahfLh/MAi4oQLNu8cMnIBsMLwxyhzHontJf+?= =?us-ascii?q?RZ22ZlLk+Nkhj/+8m94odt/zxftPw9+cFAV776f7kjQrxDEDsmKWE169b1uhTF?= =?us-ascii?q?UACC+2ETUmQSkhpPHgjF8BT3VYr/vyfmquZw3jSRMMvrRr42RDui9b9mRxDmiC?= =?us-ascii?q?gFNzA3/mLZhNFugq1Hux+uvQBzzpTObY2JKPZzfKXQds4aS2pbWcZRUjRMDIai?= =?us-ascii?q?YIsJCeoOI/pYr4ngrFYSsBSxHwysD/7oxD9Jgn/22bM10/48GgzB3wwvAdQOsH?= =?us-ascii?q?LKo9XpNKcdS/26w7PNzTXGbvNW3TP955bSch06rvGMWKh/ccvVyUU1CwzFiVCQ?= =?us-ascii?q?pJXjMjiI2OoNtG2b4PBhVeKpk2MnrB1+rSKqxscokIXJgZgVyl/c+SV4xoY1P9?= =?us-ascii?q?y4R1Rhbd6qCptdsTyROYhuQs46XW1kpCI3xqcFtJO7ZiQG1ZUqyh/FZ/CacYWF?= =?us-ascii?q?4xTuX/uLLzhinnJqYre/ig6y8Ue+zu38UdG50FNQoSpEltnAr3EN1wDO5sSeRP?= =?us-ascii?q?tx40Ws1DeV2wDc7eFEJk80la7FJJI73rEwkZ8TvVzCHi/whkr2kLebels49uWs?= =?us-ascii?q?8ejqYbXrqoWBO4J1iwzyKLkil86+DOggNwgBRWmb+eCy1L35+k35Ra1Hjv4ona?= =?us-ascii?q?nftpDVO9gbpq6jDABIyIkj7hO/Dzai0NQcg3YHNklIeB2Cj4fzOlHOJOr0Auu4?= =?us-ascii?q?g1SpiDtr3ezJPqX9ApXRKXjOiKvucqx4605Y0QYzydFf54lICrwaO/LyWkrxtM?= =?us-ascii?q?TCARMjMgy0xfznCNRn2Y8EV2KPGPzRDKSHslaU5u81Iu+BLNsOuDP8IeMN7v/0?= =?us-ascii?q?gHl8n1hYf6iq3pYRLnGzA6I1DV+eZC/Pj9EHHHsK9iMyRemirVyGVTNJLyKxUq?= =?us-ascii?q?Q66y07AY6vCILCQoSgmpSO2S66GttdYWUQWQPEKmvha4jRA6REUymVOMI0ymVV?= =?us-ascii?q?B4jkcJco0FSVjCG/zrNmKuTO/ShB7MDs0dF046vYkhRgrGUoXfTY6HmESiRPpk?= =?us-ascii?q?1NXyU/hfktrkl0y1PF2q990aQBSI5joshRWwJ/Dqbyiux3D9eoBFDEd9aNDVe6?= =?us-ascii?q?G5CoWG5vCN02xNAKbgB2HNDw1h0=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVAQDhaiJcgLCmVdFkGwEBAQEDAQEBB?= =?us-ascii?q?wMBAQGBZYFWBYEPgQIng36BHYJekBeCDYoZj0UNI4RJAoJ3GgcBBDQSAQMBAQI?= =?us-ascii?q?BAQEBARMBAQkNCQgnJQyCOiKCbgEBAQECASMdARsSCwEDAQsGBQsNDR0CAiIBE?= =?us-ascii?q?QEFARwGG4MbgWgBAw0ID5tOPIsZgRIFAReCdwWELQoZJw1egTcCBhKMLReBf4Q?= =?us-ascii?q?jgSgZAYMXVYJbglcCiXyGZ5BoCYcShjyEGxiBYE2POYpfg3uLQA8hgRMpgXczG?= =?us-ascii?q?iNQMYI7CYISDAwLfwEJgkGBPoNWhV0kMItygj4BAQ?= X-IPAS-Result: =?us-ascii?q?A0CVAQDhaiJcgLCmVdFkGwEBAQEDAQEBBwMBAQGBZYFWBYE?= =?us-ascii?q?PgQIng36BHYJekBeCDYoZj0UNI4RJAoJ3GgcBBDQSAQMBAQIBAQEBARMBAQkNC?= =?us-ascii?q?QgnJQyCOiKCbgEBAQECASMdARsSCwEDAQsGBQsNDR0CAiIBEQEFARwGG4MbgWg?= =?us-ascii?q?BAw0ID5tOPIsZgRIFAReCdwWELQoZJw1egTcCBhKMLReBf4QjgSgZAYMXVYJbg?= =?us-ascii?q?lcCiXyGZ5BoCYcShjyEGxiBYE2POYpfg3uLQA8hgRMpgXczGiNQMYI7CYISDAw?= =?us-ascii?q?LfwEJgkGBPoNWhV0kMItygj4BAQ?= X-IronPort-AV: E=Sophos;i="5.56,397,1539640800"; d="scan'208,217";a="290144710" Received: from mail-it1-f176.google.com ([209.85.166.176]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 25 Dec 2018 18:42:52 +0100 Received: by mail-it1-f176.google.com with SMTP id c9so18185830itj.1 for ; Tue, 25 Dec 2018 09:42:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UzxIDAz85rrB1b5T6DLiui/o/sKDVsuBdll8d4VKC9g=; b=Hm1MBDao7aVuiBM67ew5datYJnpcaJ5RzR4ZpESvtJD2+Uq9rjnYtl44ADX/wv/GzN 3OI+MaQteoW603+GasrUkXhhrHPoZXoRGsmdj6sy5vZHuS/snS5QIOR+W2qXPUsc96Sl y0UCeChHNBs8TS+3CG0wTbtXJWZ+g//X5HiVaIf7Ma65xQ/SZuDnYmuO1d25seJk7kic y0h7fTXk8ULsIZJMEK2h7kTS1Ewkl+oTsMOq3/rWok7Lj8s7MCh4/u5Y75wmbKDNBFVh 4Ma/LxCO4OoPatHKHqp21ImEBZYNbLzJtXkv9jSVd6bTKwQfstbquLetoZsK7yBAOsE0 yUFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UzxIDAz85rrB1b5T6DLiui/o/sKDVsuBdll8d4VKC9g=; b=k/7l73gNZNpOpj1oWJao1oXN1sHw+cK/5/yCKeY0MB0oFPcQyJDGHqbFOgJ4AISOey 0J7J7mzM25zs4r3AZcEtUjbvwsJZ1RGCqHGeavqdrxaper9DYpnJhgVJ/dktgGsWpxz3 ELR2ObfoF1X9s3963RLkdcTGmQwnbpqlGTYUljM8UWo9I23uelts7P9sRx7iDLLa5luQ Rpue1t/C4qN1omgv7P0c2i3s5VSZzIf9BDnbts68okoMaFQ1uuk+Ecf8OJ6P6JkODL1U 0zNWnzjlRP55Ic4z+GdsijbQLuLsNxA+YHlFHiIy5qAMMFR/7xgTwPeb1e3CwQ1vuYRJ c7EA== X-Gm-Message-State: AJcUukdth3vW8qBj5dXz2Qf0+YSyLhq/471vnbePXIc05CTcRCHwYnrJ qjJwcPWoViRXsc5qgcuiLlLV7FaSH5CidyT8ply+gw== X-Google-Smtp-Source: ALg8bN7Q5gGgwpjVRJvkCGwriY//6KyujOwUKWmFqyp2z0Mc8A9+VqnEPH1R0ynximjG09c+wYJp5ZgCOVOYDp7MQ+A= X-Received: by 2002:a24:7fc3:: with SMTP id r186mr10665126itc.178.1545759771316; Tue, 25 Dec 2018 09:42:51 -0800 (PST) MIME-Version: 1.0 References: <20181225095046.GA19776@airen-no-jikken.icu> In-Reply-To: <20181225095046.GA19776@airen-no-jikken.icu> From: Kenneth Adam Miller Date: Tue, 25 Dec 2018 12:42:41 -0500 Message-ID: To: katherine Cc: caml users Content-Type: multipart/alternative; boundary="00000000000013d7a5057ddc3e27" Subject: Re: [Caml-list] Opam improvement request Reply-To: Kenneth Adam Miller X-Loop: caml-list@inria.fr X-Sequence: 17268 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: --00000000000013d7a5057ddc3e27 Content-Type: text/plain; charset="UTF-8" Yeah automating that is what I am talking about. I don't think I want to do much in terms of meta data as much as I want the system of changes for any one opam command to be atomic and revertible without having to rebuild. Basically, opam shouldn't immediately delete things, but instead move them while building new ones. Upon doing everything necessary, do a folder swap to make the actions take. You have the right idea, I think I was just much too wordy about it. On Tue, Dec 25, 2018, 4:50 AM katherine i'm pretty new to opam here, but do know that many OS package managers, > like pacman or freebsd's pkg, will generally keep a package cache, so > that, if something goes wrong, it's possible to check the package > manager log for which packages have changed and then reinstall the > (already on disk) previous versions. is that something like you mean? > > obviously that could be automated in a couple of ways while still > keeping things simple, like having the package manager write a file for > the most recent action, with before and after state (statefulness oh no > D=), and having something like a revert command that tries to reinstate > that most previous version. > > add also some configuration for how many versions of a package should be > kept at a time (2 or 3 or something), with the older versions deleted > automatically, and the cache size could also be kept fairly low. > > On Mon, Dec 24, 2018 at 04:10:44PM -0500, Kenneth Adam Miller wrote: > > 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 > -- 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 --00000000000013d7a5057ddc3e27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah automating that is what I am talking about. I don= 9;t think I want to do much in terms of meta data as much as I want the sys= tem of changes for any one opam command to be atomic and revertible without= having to rebuild. Basically, opam shouldn't immediately delete things= , but instead move them while building new ones. Upon doing everything nece= ssary, do a folder swap to make the actions take.

You have the right idea, I think I was just much too wo= rdy about it.

On= Tue, Dec 25, 2018, 4:50 AM katherine <shmibs@airen-no-jikken.icu wrote:=
i'm pretty new to opam here, b= ut do know that many OS package managers,
like pacman or freebsd's pkg, will generally keep a package cache, so that, if something goes wrong, it's possible to check the package
manager log for which packages have changed and then reinstall the
(already on disk) previous versions. is that something like you mean?

obviously that could be automated in a couple of ways while still
keeping things simple, like having the package manager write a file for
the most recent action, with before and after state (statefulness oh no
D=3D), and having something like a revert command that tries to reinstate that most previous version.

add also some configuration for how many versions of a package should be
kept at a time (2 or 3 or something), with the older versions deleted
automatically, and the cache size could also be kept fairly low.

On Mon, Dec 24, 2018 at 04:10:44PM -0500, Kenneth Adam Miller wrote:
> I'm not sure if opam already does this, and I'm not unhappy wi= th opam at
> all about it, but I'd like to be able to have installation or upgr= ade
> 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 w= ill 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<= br> > 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 betwee= n
> combinations of package versions. I don't want to manage specifica= tion
> 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 man= age
> it for me. I don't want to track files manually.
>
> I've had some scenarios where opam tells me how to restore my stat= e, 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 ver= sion
> change. opam packages can change rather quickly too, so I remember I o= nce
> just had to quit and come back, and doing an opam update got the chang= es to
> take successfully because someone pushed a change that fixed it. It wo= uld
> nice if, if there are any errors, I could keep my old state without ev= en
> 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 st= ates.
> 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 ca= use 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 wh= ere 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 direc= tory,
> that would be really fantastic.
>
> Often, doing an update or upgrade means that all the packages that dep= end
> on it have to get rebuilt. OCaml is fantastic for having such a fast b= uild
> 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 break= s
> that I'm talking about.
>
> It makes sense to me to think of opam package installs as being in a k= ind
> of git staging area, where I can consider them tentatively and test it=
> against a particular package, but easily and quickly revert back to ot= her
> built packages (without needing to rebuild something again unnecessari= ly)
> that I know are working.
>
> --
> Caml-list mailing list.=C2=A0 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
--00000000000013d7a5057ddc3e27--