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 9C6B75D5 for ; Thu, 3 Jan 2019 16:46:38 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.56,435,1539640800"; d="asc'?scan'208";a="362474249" Received: from sympa.inria.fr ([193.51.193.213]) by mail2-relais-roc.national.inria.fr with ESMTP; 03 Jan 2019 17:46:37 +0100 Received: by sympa.inria.fr (Postfix, from userid 20132) id 72C3E82565; Thu, 3 Jan 2019 17:46:37 +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 7552D824CF for ; Thu, 3 Jan 2019 17:35:25 +0100 (CET) Authentication-Results: mail2-smtp-roc.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=3AI2u9hROFsh0mIjeUYx0l6mtUPXoX/o7sNwtQ0KIM?= =?us-ascii?q?zox0Ivv4rarrMEGX3/hxlliBBdydt6oUzbKO+4nbGkU4qa6bt34DdJEeHzQksu?= =?us-ascii?q?4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPERvjKwV1?= =?us-ascii?q?Ov71GonPhMiryuy+4ZLebxlLiTanfb9+MAi9oBnMuMURnYZsMLs6xAHTontPde?= =?us-ascii?q?RWxGdoKkyWkh3h+Mq+/4Nt/jpJtf45+MFOTav1f6IjTbxFFzsmKHw65NfqtRbY?= =?us-ascii?q?UwSC4GYXX3gMnRpJBwjF6wz6Xov0vyDnuOdxxDWWMMvrRr0vRz+s87lkRwPpiC?= =?us-ascii?q?cfNj427mfXitBrjKlGpB6tvgFzz5LIbI2QMvd1Y6HTcs4ARWdZXshfSTFPDI2/?= =?us-ascii?q?YYsIDeUBM+lXoJXmqlsBsRezHxOhCP/zxjNWgHL9wK000/4mEQHDxAEuGdUOsG?= =?us-ascii?q?nVrNXuKawcUP66zLLTwjrddfNWxSr25Y/MchAmvPGMXKlwfdDeyUYxDAPKlUuf?= =?us-ascii?q?qZb5Pz6O0eQCr3KU7+9kVeK3kW4nrBt9rSSoxscpk4TEgJ8exF7D9SV82ok1JN?= =?us-ascii?q?u4RVZ8YdG4CpRQsiWaO5FxQsM4TGFkoCk6yrwauZ67YSgF044ryALYa/yCdYWD?= =?us-ascii?q?/xHtVP6JLDp2hn9pYq+zihWw/ES61OHxWca53ExEoydElNTHq2oD2AbJ6sedT/?= =?us-ascii?q?tw5keh1iiL1wDU8uxEJFo7lavfK5I72LEwkIYTsUXYHi/ygkr2l6+Wel8l+uiu?= =?us-ascii?q?5eTnZa3qpp6aN4BqlgHzKqojl86lDeglMQUDXXKX9fqz2bDs50H0TrRHguUzkq?= =?us-ascii?q?bDsZDaIcobprS+Aw9Qyosj7xG/Dyqn0NQDh3UHI0xKeAmcgIf3IVHOPOv1DfCj?= =?us-ascii?q?jFu2lTdrw+jGPqfmApnXMnfDl7Lhca5n60FA0Aoz0cxf55VMB74dOv3zX0vxuM?= =?us-ascii?q?XcDh84KAy03/3qCM5914MbQWKAGLWVMKLUsV+S5+IgOfOAZIEPuGW1F/9w7Pfr?= =?us-ascii?q?iTo9mEQBVaivx5oeLn6iWrxFLkOfbGbsyv4NGGJCmws6SOHwwAmBXDhVamqyVq?= =?us-ascii?q?414zQ6DIarF6/MQ4mshPqK2yLtTbNMYWUTLleREGygWIifUfoWdGrGJsh8kydC?= =?us-ascii?q?WrW6QYI7yTmpvwb/z6J9Kazf/ShO5sGr78R8++CGzUJ6zjdzFcnIljjVFzglzF?= =?us-ascii?q?NNfCc/2eVEmWI4z16C1aZihPkBSY5U7PpMVh8gMtjXyOkoVYmuCDKERc+ATROd?= =?us-ascii?q?evvjGSs4F45jxNQHZkJlAdLkhRfGjXLzXu0l0oeTDZlxyZrymnj8I8EnkiTD3a?= =?us-ascii?q?glyVAgXspUMWS9huh+8QbUVdfE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BqDQC3OC5c/yT0uyVjH4NTgQ8FSiESJ?= =?us-ascii?q?4x4mymCSYkACAUjhEkCCIIQBwEDNBIBAwEBAgEBAQEBbBwMgjopAYJnBoEJCyE?= =?us-ascii?q?lDwFHBgGDNYIFC6dYhEFAhRYPgm2LKT+EI4EoGQGBUQsCAgKBGYYjAol8lnVaB?= =?us-ascii?q?wKCJQSEaYpvCoFWTYdRh2iJWYEGg3uLT4FdIYFWMxojUIJtCIIeDAt/AQgBgkG?= =?us-ascii?q?FFIVAQTABijQBAQ?= X-IPAS-Result: =?us-ascii?q?A0BqDQC3OC5c/yT0uyVjH4NTgQ8FSiESJ4x4mymCSYkACAU?= =?us-ascii?q?jhEkCCIIQBwEDNBIBAwEBAgEBAQEBbBwMgjopAYJnBoEJCyElDwFHBgGDNYIFC?= =?us-ascii?q?6dYhEFAhRYPgm2LKT+EI4EoGQGBUQsCAgKBGYYjAol8lnVaBwKCJQSEaYpvCoF?= =?us-ascii?q?WTYdRh2iJWYEGg3uLT4FdIYFWMxojUIJtCIIeDAt/AQgBgkGFFIVAQTABijQBA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.56,435,1539640800"; d="asc'?scan'208";a="362473119" Received: from antislash.info (HELO mail.antislash.info) ([37.187.244.36]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jan 2019 17:35:24 +0100 From: Louis Gesbert To: caml-list@inria.fr, Kenneth Adam Miller Date: Thu, 03 Jan 2019 17:35:11 +0100 Message-ID: <7228202.vLAhXhkjka@agaric> Organization: OCamlPro In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4673717.226Jk9O5Lx"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Validation-by: louis.gesbert@ocamlpro.com Subject: Re: [Caml-list] Opam improvement request Reply-To: Louis Gesbert X-Loop: caml-list@inria.fr X-Sequence: 17269 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: --nextPart4673717.226Jk9O5Lx Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" This kind of feature wishes are best directed to the opam tracker (https://= github.com/ocaml/opam/issues); but let me give a quick answer: =2D we are working on allowing a binary cache, and there are ongoing experi= ments for that. The main issue is relocatability of packages themselves (wh= ich is not relevant in your case, but still). The point is that you would s= till do a `opam switch import backup.export`, but the recompilations wouldn= 't need to be done again since the packages are at the same versions, and w= ith the same installed dependencies. =2D using the hook mechanism in opam 2.0 [1], you could pretty easily add s= napshotting to your opam switch. For example, create a git repository in yo= ur prefix dir, and use `git commit -a" as a `post-session-commands` hook. Y= ou can then freely checkout to previous revisions of the switch (all opam m= etadata is included in the `.opam-switch` subdir, so that should be safe, a= s long as opam is not running while you do it of course). Hope this helps, Louis Gesbert - OCamlPro [1] http://opam.ocaml.org/doc/Manual.html#configfield-pre-session-commands > - Kenneth Adam Miller, 24/12/2018 16:10 - > 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 mea= n. >=20 > 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 differe= nt > 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. >=20 > 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. >=20 > 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 state= s. > I just want to always have some working system. >=20 > 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 director= y, > that would be really fantastic. >=20 > 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. >=20 > 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. >=20 >=20 --nextPart4673717.226Jk9O5Lx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEbvv1DIVPNISNNdcMGDmcR4apvJgFAlwuOb8ACgkQGDmcR4ap vJgSNwgAmxHZylGqS+J+fcVf9B5oG8V+KlQywLRU7A90rt9mbbGWHFO6WChBCqZe tzmVTkaqdLZlXUw/Ulr8v3AKEvuZ8LIVkCvZF70h6Q26Z1aSF6+AbCBg4bgSGoHp rmd889nPc6Uk2sP0QD0Cp45D3U3+Tqic1klynumESbBMC7oYlz0l9mwJf0eP5CJz 7ufi72DYtCLZB88mLlKUldTcPwfukDw8lQiVjwErli2JypTE2tGuQKr5xPOGt0jL ECKzPw5oyxL1hse+9lTy3lLUmbdZrOG61iXAOdd1z96zS8moy7FWa7hvYnysOuOE T7xiYXIbc6q1+HWHAvF9MRvuNWlmDg== =84T3 -----END PGP SIGNATURE----- --nextPart4673717.226Jk9O5Lx--