[ANN] Set up OCaml 2.0.0-alpha

Ecosystem
1

This is the announcement of the first alpha release of setup-ocaml v2. This includes quite a few changes, including reliable cache, as mentioned in a recent post.

There are so many changes, so I would like to list only the notable changes. (The full changelog can be found at the bottom of the post.)

The “ocaml-version” input is now named “ocaml-compiler”

This was changed because calling it “OCaml Version” is not appropriate enough, e.g. to use the new variant naming convention introduced from 4.12.

32 bits compiler support

Semver-style version matching support

With the naughty exception of 4.02.2 , point releases are meant to be strictly compatible, so once OCaml dev team release a new point release, upgrading should be a no-brainer. With that in mind, it’s obviously not smart to rewrite every workflow every time a new point release is released, so you can now specify versions in the style like 4.12.x.

Reliable cache feature

The action supports not only the compiler cache, but also the dune cache. However, note that it is not available on the macOS runners until opam 2.0.9 is released. The dune cache is actually quite powerful for large projects, if you’re interested in it, check out the comparison section of ocaml/setup-ocaml#66. The reliable cache feature uses the @actions/cache package internally, and I worked with the GitHub team to make it fast enough for setup-ocaml to be up to 4x faster. For the Ubuntu runners, you can set up your environment with cache in about 30~40 seconds at the fastest.

Automatic pinning and depext handling of local packages

For example, if you have a very large number of local packages, like the Irmin project, it can be quite a pain for a human to have to write a script to pin them all in your workflow. The action pins and depext the local packages if they exist in the repository by default. You can also use the glob pattern to select which local packages to handle, as described here.

11 Likes
2

Just like v1, I also published the v2 tag as an alias for the latest v2 release, and I recommend using it.

1 Like
3

Nice work! Kinda random question here. I spend a lot of time studying old code. They always have great comments! The thing is they all have different build instructions. In the older repos you will have .depends, myocamlbuild.ml, -use-ocamlfind, configure.inetc. Is there some command or script that can consume old package formats and convert them to dune or updated setup style? Sorry for the ignorance displayed in the question. Here is the kind of thing I do to practice. I might download the calendar module and convert it to a dune/setup build to see how that might be done. Anything out there that already does this?

Thank you.

4

I have not yet got the gist of your question, but I can say for sure that setup-ocaml only sets up and initialises opam and then install compiler packages. It’s probably not the best thread to post the question, so I would post a new one.

1 Like
5

I don’t think there’s an automated tool for this - it tends to be relatively straight-forward to do by hand. For calendar specifically, the 3.x branch builds with Dune (as it happens, I also did a Dune port in 2019!)

1 Like
6

@dra27 nice. Thank you, sir.

7

Trying it on bap so far no problems detected. But no significant performance improvements out of the box. And this brings us to the question: is there anything specific we need to do to enable caching?

From the documentation, it looks like that everything is automatic and transparent (except that dune cache is disabled by default). Then if it is true, it brings me to the next question, what is the caching model? I.e., is the cache stored inside the runner or it could be shared by runners, and, in the latter case, is it shared across all OCaml runners or just inside the repository (so rerunning the action will benefit from it)?

1 Like
8

Thank you for trying this. First, the action defaults to caching only the OCaml compiler and package sources. These caches are shared within the repository in the most efficient way. (On the Windows runners, the Cygwin cache is included as an exceptional case.)

For example:

  • Compiler cache: Shared in the repository level with the same compiler version.
  • opam download cache: Shared at repository level with the same opam repository and compiler version.
  • Dune cache: Shared in the repository level with the same compiler version and workflow.

If you want to significantly speed up steps like opam install, I highly recommend you try the dune cache. (However, at this stage it only works on Ubuntu and Windows, so macOS should be excluded.)

Remember, there are just two kinds of OCaml project: those which have switched to Dune, and those which need to!

2 Likes
9

I suspect that the question was raised because the workflow just after merging PR did not use the cache, but it is due to the strange specification of GitHub Actions and should be much faster from the next workflow run!

2 Likes