Upgrading local OCaml switches

Learning
1

What is the standard way of keeping up-to-date with OCaml releases?

Let’s say that we have a repository with a local switch:

opam switch create . 4.10.0 --deps-only

Now we want to update to OCaml 4.12.0; Do you need to first remove the existing switch:

opam switch remove .

and then create a new one:

opam switch create . 4.12.0 --deps-only

or is there another preferred way?

2

You can upgrade an existing local switch this way:

opam install ocaml-variants.4.11.2+flambda --unlock-base

At least something similar to that, I’m on mobile right now so I can’t check. But I did this recently and it should upgrade and rebuild all packages as necessary.

1 Like
3

why would you want to delete the old switch? Just create a new one, use “opam list” to get a list of installed packages, a little perl magic to get the list of names and nothing else, and do an “opam install” with that list in the new switch context ?

I have … 29 switches installed: basically every installable version of OCaml from 4.02.0 thru 4.13.0~alpha02 .

4

@OCamlUser command is good, for opam 2.0 ; for 2.1, the option is --update-invariant.

If you don’t want to update manually your compiler, with 2.1 you can automate it. It introduces switch invariants, a package formula which must be satisfied on every upgrade and install.

You can define your switch invariant as ocaml with no version to have always the most up-to-date (including variants), or ocaml-base-compiler to have only OCaml releases.

opam switch set-invariant ocaml-base-compiler

Once that done, you will have the latest OCaml compiler at each upgrade.

1 Like
5

You can also do opam switch export [filename] to put the current list into a file by the name of ‘filename’, and then in the new switch do opam switch import [filename] to install the packages in the new switch.

3 Likes
6

Oh, thank you, I didn’t know this. Tough to remember everything that a piece of software does. Tough to even remember all the great things it does.

7

I am using:

  • local (to each repository) switches and when I tried updating the OCaml version of one of them - I could find any docs;
  • packages listed in a dune-project file and an auto-generated opam file from the dune-project file
  • opam lock files

So I found deleting the switch and recreating it to be a workaround, until I found something better

8

My 2c on a local workflow. I don’t migrate switches between compiler version I
just create a new one, relying on opam files to know their dependencies and will
add them if they’re missing. Similar to @mudrz

# Create the new switch appending project name eg thrift
opam switch create 4.10.1-thrift 4.10.1

# Use direnv to automatically switch to the projects switch
echo "use ocaml 4.10.10-thrift" > .envrc

# Install the dependencies as per the opam file, something like 
opam depext -yt thrift
opam install --deps-only -td .

# Install various pieces like merlin/lsp/ocamlformat cause they're usually not included in opam files as a dependency.
# Throw away the old switch when my SSD is full.

Many of these steps should be easier and more streamlined, driven off the existing config in opam / dune.

9

apt-get update is the standard way of keeping up to date with OCaml releases (and ed is the standard editor of course). ;p