Note! This is not our usual time! Past meetups have been at 7pm (U.S. Central). This one is happening at 1pm (U.S. Central). This meetup should be easier for people in Europe to attend.
Please join us at the next OCaml Cafe, a friendly, low stakes opportunity to ask questions about the OCaml language and ecosystem, work through programming problems that you’re stuck on, and get feedback on your code. Especially geared toward new and intermediate users, experienced OCaml developers will be available to answer your questions. Bring your code and we’ll be happy to review it, assist with debugging, and provide recommendations for improvement.
This month, David Allsop of OCaml Labs and the University of Cambridge will present on OPAM, the OCaml package manager. After introducing OPAM, David will discuss the new features of OPAM 2.1, just released at the beginning of August. Following David’s talk, we will open the discussion to all things OCaml-related.
Yes, thanks to David, Anil, and everyone else who participated, that was very educational in a variety of ways!
Just to follow up on my relatively banal question: rather than describing the painful details of my particular dependencies, lockfile, etc., I suspect the root issue is easily replicated by the result of running the most basic local switch creation command in the e.g. ocaml/opam:ubuntu-lts-ocaml-4.12 container:
chas@t440p:~$ docker run -it ocaml/opam:ubuntu-lts-ocaml-4.12 bash
opam@5a99b9f5af57:~$ opam switch create . ocaml-system
[ERROR] No compiler matching 'ocaml-system' found, use 'opam switch list-available' to see
what is available, or use '--packages' to select packages explicitly.
Leaving aside entirely whether one should be using those images for non-CI workloads (guilty as charged to date), I don’t understand what’s going on here. (FWIW, the result is the same, even if I unpin ocaml-base-compiler as it comes, and if I install a completely fresh switch besides the stock 4.12 that comes with the container.)
David mentioned that there are only some rare cases left where one needs to care about ocaml vs ocaml-system vs ocaml-base-compiler; it seems this is one?
Ah, I think I misunderstood earlier - the issue here is that the base images don’t have a system compiler! Each of the docker images contains a single switch with ocaml-base-compiler at the given version. You can of course install a system compiler (sudo apt-get install -y ocaml-nox)
If you’re going to that, though, I’d recommend using the unbuntu-lts-opam tag instead (or ubuntu-20.04-opam tag - I can’t remember if it’s aliased at that level). The *-opam tags are initialised but with no switches
Ohhhhkay. The actual meaning of “system compiler” didn’t dawn on me until just now, seeing the apt invocation.
I guess my next question would be, why does opam lock . put a "ocaml-system" {= "4.12.0"} entry in the resulting file (in addition to "ocaml" {= "4.12.0"})? Doing so would seem to make the result far less portable.
opam lock lockes dependencies given what is in your switch. If you have ocaml-system installed and it is a dependency of the package you want to lock, it adds it. You can change by hand, changing it to ocaml-base-compiler dependency, or change it to ("ocaml-base-compiler" {= "4.12.0"} | "ocaml-system" {= "4.12.0"}), to try to install system one if present. If you just keep ocaml dependency, you permit install of ocaml variant packages.
Yes, I understand that; except that I never use system-level ocaml installations, only opam-managed ones, the project in question doesn’t mention ocaml-system in its opam file, and running opam list in the environment that is producing the lockfile shows no ocaml-system package.
Besides that though, insofar as these meta packages don’t signify anything developers should care about (maybe that’s not the case?), shouldn’t opam lock normalize such things to just "ocaml" {= "N.NN.N"}? Otherwise, lockfiles will end up containing e.g. ocaml-system entirely incidentally, as seems to be happening in my case.
Edit:
In attempting to validate my suspicions re: opam lock adding the spurious ocaml-system dependency, I discovered that they were unfounded. Rather, that dependency comes about because opam switch create . --deps-only (i.e. creation without reference to a lockfile) results in ocaml-system being installed in that local switch (why?)…and from there, yes, ocaml lock does what it’s supposed to do.
opam is not aware of the meaning of packages, it treats their metadata from opam files*. From opam view, ocaml is just a (virtual) package that depends on ocaml-system | ocaml-variants | ocaml-base-compiler, each one having its build/install instruction. It doesn’t know that ocaml-system.x is a package of the ocaml compiler based on system install, neither that it can be substituted by ocaml-base-compiler.x.
On switch creation, if you don’t specify a compiler, opam will try to install system one as a priority (via opam default config file), to minimise switch creation time (no compiler compilation). With relocatable compiler, as showed David in his talk, it will be possible to install new switches with a compiled compiler within seconds and not minutes.
(*) Metadatas contains some information about the package nature, viaflags: field: virtual conf, compiler, etc. And it used by opam to treat them differently, e.g. a switch needs a compiler.
Granted, but I simply don’t have a system compiler installed, yet somehow ocaml-system is present in the resulting switch.
I guess what I’m saying is that opam (or perhaps opam lock) should be aware of these things (at least insofar as ocaml dependencies go, since they are special compared to other packages), and do the thing that will result in expected / positive outcomes.
If a canonical .opam file lists a simple "ocaml" dependency, it seems like emitting anything besides this in the lockfile is sure to cause problems. The whole raison d’être of lockfiles is to support reproducible builds; even if I were using a system compiler, letting that incidental fact leak into a generated lockfile sabotages reproducibility expectations. (Likewise to any suggestion of editing lockfiles as a workaround.)
The video of @dra27’s talk on OPAM is now available: David Allsopp, "OPAM: The OCaml Package Manager" - YouTube. Thanks so much for the great talk, David! And thanks to everybody who attended! (The video starts a couple of minutes into the talk because yours truly forgot to start recording. D’oh!)
We already have some ideas for the next meeting but if there’s a topic that you’d like to hear about or are interested on presenting on, please message me.
