caml-list - the Caml user's mailing list
 help / Atom feed
From: Kenneth Adam Miller <>
To: caml users <>
Subject: [Caml-list] Opam improvement request
Date: Mon, 24 Dec 2018 16:10:44 -0500
Message-ID: <> (raw)

[-- Attachment #1: Type: text/plain, Size: 3354 bytes --]

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:
Bug reports:

[-- Attachment #2: Type: text/html, Size: 3353 bytes --]

             reply index

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-24 21:11 Kenneth Adam Miller [this message]
2018-12-25  9:01 ` SF Markus Elfring
2018-12-25  9:50 ` katherine
2018-12-25 17:43   ` Kenneth Adam Miller
2019-01-03 16:46 ` Louis Gesbert

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

caml-list - the Caml user's mailing list

Archives are clonable: git clone --mirror

AGPL code for this site: git clone public-inbox