[Caml-list] Attn: Development Editor, Latest OCaml Weekly News

Alan Schmitt
2025-06-10T13:36:49Z

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

Hello

Here is the latest OCaml Weekly News, for the week of June 03 to 10,
2025.

Table of Contents
─────────────────

Portable External Dependencies for Dune Package Management
Semgrep is hiring OCaml developers to work on the static analysis engine
Elpe, a config-as-code build system written in OCaml+Rust
Dune dev meeting
Other OCaml News
Old CWN

Portable External Dependencies for Dune Package Management
══════════════════════════════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/portable-external-dependencies-for-dune-package-management/16767/1>

Steve Sherratt announced
────────────────────────

Dune lock directories record the names of any system packages needed
to build projects or their dependencies. We've recently changed how
this works in the interest of portability.

Background on `depexts' in Opam
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

A system package, or external dependency, or `depext' as I'll refer to
them from now on, is a non-Opam package which must be installed in
order for some Opam package to be built or for code in a package to be
executed at runtime. These packages must be installed by the system
package manager, or by some other non-Opam means such as manually
building and installing the package from source. Common types of
`depext' are build tools such as the `pkg-config' command, often run
to determine linker flags while building a package, or shared
libraries such as `libgtk', which an OCaml project might link against
to create GUIs.

Opam usually installs `depexts' automatically. Opam knows how to
invoke many different system package managers (such as `apt' or
`pacman'), so when installing a package with `depexts' Opam can run
the commands appropriate to the current system to install the required
packages using the system's package manager. For this to work, Opam
needs to know the name of the package within the package repository
appropriate to the current system, and these names can vary from
system to system. For example the `pkg-config' command is in a package
named simply `pkg-config' in the `apt' package manager on
Ubuntu/Debian systems, whereas in the third-party `homebrew' package
manager on MacOS it's in a package named `pkgconf'. In order to
determine the right package name for the current system, the package
metadata for Opam packages with `depexts' contains a list of all the
different known package names along with the conditions under which
that name is correct. Here is that list for the `conf-pkg-config' Opam
package:
┌────
│ depexts: [
│ ["pkg-config"] {os-family = "debian" | os-family = "ubuntu"}
│ ["pkgconf"] {os-distribution = "arch"}
│ ["pkgconf-pkg-config"] {os-family = "fedora"}
│ ["pkgconfig"] {os-distribution = "centos" & os-version <= "7"}
│ ["pkgconf-pkg-config"] {os-distribution = "mageia"}
│ ["pkgconfig"] {os-distribution = "rhel" & os-version <= "7"}
│ ["pkgconfig"] {os-distribution = "ol" & os-version <= "7"}
│ ["pkgconf"] {os-distribution = "alpine"}
│ ["pkg-config"] {os-distribution = "nixos"}
│ ["pkgconf"] {os = "macos" & os-distribution = "homebrew"}
│ ["pkgconfig"] {os = "macos" & os-distribution = "macports"}
│ ["pkgconf"] {os = "freebsd"}
│ ["pkgconf-pkg-config"] {os-distribution = "rhel" & os-version >= "8"}
│ ["pkgconf-pkg-config"] {os-distribution = "centos" & os-version >= "8"}
│ ["pkgconf-pkg-config"] {os-distribution = "ol" & os-version >= "8"}
│ ["system:pkgconf"] {os = "win32" & os-distribution = "cygwinports"}
│ ["pkgconf"] {os-distribution = "cygwin"}
│ ]
└────

`depexts' in Dune
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

Dune doesn't install `depexts' automatically as the Dune developers
are a little nervous about running commands that would modify the
global system state. This may change at some point, but for now Dune
only provides support for listing the names of `depexts', leaving it
up to the user to install them as they see fit.

The `dune show depexts' command can be used to list the `depexts' of a
project. For that command to work the project must have a lock
directory. Here's an example of listing the `depexts' of a project:
┌────
│ $ dune pkg lock
│ ...
│ $ dune show depexts
│ libao
│ libffi
│ pkgconf
│ sdl2
└────

I ran these commands on a Mac with homebrew installed, so the package
names are from the homebrew package repo. Each package listed there is
one of the `depexts' of a package whose lockfile appears in the
project's lock directory. Let's look at how this information is
stored. Using `pkg-config' as an example:
┌────
│ $ cat dune.lock/conf-pkg-config.pkg
│ (version 4)
│
│ (build
│ (run pkgconf --version))
│
│ (depexts pkgconf)
└────

The relevant part for us is the `depexts' field. The current released
version of Dune only stores the package's `depexts' for the system
where `dune pkg lock' was run. The command `dune show depexts' simply
concatenates the `depexts' fields from each lockfile in the lock
directory.

When thinking about portable lock directories I always like to imagine
what the experience would be using Dune for a project where the lock
directory is checked into version control. I frequently switch between
using two different machines for development - one running Linux and
the other running MacOS. If I was to check in the lock directory I
just generated on my Mac, and then check it out on Linux and continue
development, `dune show depexts' would show me a list of packages for
the wrong system!

Portable `depexts' in Dune
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

To make `depexts' portable, one's first instinct might be to use the
same approach as taken with the `depends' field outlined [here],
listing the `depexts' for each platform for which the solver was
run. Indeed such a change was added to the Dune Developer Preview when
we first introduced portable lock directories, however we quickly
realized a problem.

The `depends', `build', and `install' fields of a package rarely vary
between OS distribution. It's reasonably common for those fields to be
different on different OSes, but very rare for them to also be
different on different OS _distributions_. As such, it's expected that
users will elect to solve their projects for each common OS, but there
would be little value in solving projects for each OS distro. In fact
solving for multiple distros would slow down solving and bloat the
lock directory, and users would somehow need to come up with a
definitive list of distros to solve for.

_But_ the `depexts' field is highly-dependent on the OS distro since
package names are specific to the package repository for a particular
distro. Recall that the `depexts' field in Opam package metadata lists
package names along with the conditions under which that package name
should be used, e.g.:
┌────
│ ["pkg-config"] {os-family = "debian" | os-family = "ubuntu"}
│ ["pkgconf"] {os-distribution = "arch"}
│ ["pkgconf-pkg-config"] {os-family = "fedora"}
│ ["pkgconfig"] {os-distribution = "centos" & os-version <= "7"}
└────
These conditions almost always involve the name of the OS distro, and
to make matters worse they also sometimes involve the OS _version_, as
packages can change their names between different versions of the same
OS. Evaluating these conditions at solve time for platforms with no
distro or version specified tends to result in lockfiles with _no_
`depexts' at all, since all the conditions evaluate to `false'.

The use case we have in mind for `depexts' in Dune is that a user will
solve their project coarsely, usually just for each common OS with no
consideration for distribution or version. Then when they run `dune
show depexts', the `depexts' will be listed using names appropriate to
the current machine. This means Dune needs to store enough metadata
about `depexts' to compute system-specific `depext' names at a later
time. This means storing the same names and conditions as are
currently stored in Opam files, and deferring evaluation of the
conditions until as late as possible, such as right when `dune show
depexts' is run.

The latest version of the Dune Developer Preview does just this;
translating the `depexts' field from each package's Opam file into a
Dune-friendly S-expression. After this change, the `depexts' field of
`conf-pkg-config''s lockfile is:
┌────
│ $ cat dune.lock/conf-pkg-config.4.pkg
│ ...
│ (depexts
│ ((pkg-config)
│ (or_absorb_undefined_var
│ (= %{os_family} debian)
│ (= %{os_family} ubuntu)))
│ ((pkgconf)
│ (= %{os_distribution} arch))
│ ((pkgconf-pkg-config)
│ (= %{os_family} fedora))
│ ((pkgconfig)
│ (and_absorb_undefined_var
│ (= %{os_distribution} centos)
│ (<= %{os_version} 7)))
│ ((pkgconf-pkg-config)
│ (= %{os_distribution} mageia))
│ ((pkgconfig)
│ (and_absorb_undefined_var
│ (= %{os_distribution} rhel)
│ (<= %{os_version} 7)))
│ ((pkgconfig)
│ (and_absorb_undefined_var
│ (= %{os_distribution} ol)
│ (<= %{os_version} 7)))
│ ((pkgconf)
│ (= %{os_distribution} alpine))
│ ((pkg-config)
│ (= %{os_distribution} nixos))
│ ((pkgconf)
│ (and_absorb_undefined_var
│ (= %{os} macos)
│ (= %{os_distribution} homebrew)))
│ ((pkgconfig)
│ (and_absorb_undefined_var
│ (= %{os} macos)
│ (= %{os_distribution} macports)))
│ ((pkgconf)
│ (= %{os} freebsd))
│ ((pkgconf-pkg-config)
│ (and_absorb_undefined_var
│ (= %{os_distribution} rhel)
│ (>= %{os_version} 8)))
│ ((pkgconf-pkg-config)
│ (and_absorb_undefined_var
│ (= %{os_distribution} centos)
│ (>= %{os_version} 8)))
│ ((pkgconf-pkg-config)
│ (and_absorb_undefined_var
│ (= %{os_distribution} ol)
│ (>= %{os_version} 8)))
│ ((system:pkgconf)
│ (and_absorb_undefined_var
│ (= %{os} win32)
│ (= %{os_distribution} cygwinports)))
│ ((pkgconf)
│ (= %{os_distribution} cygwin)))
└────

That's a 1:1 translation of the `depexts' field from
`conf-pkg-config''s Opam file. There's enough information there so
that the appropriate package name can be computed on demand rather
than just at solve time.

This bring us a step closer to a world where Dune users can check
their lock directories into version control with confidence that their
builds are reproducible across different platforms. To try out the
latest version of the Dune Developer Preview, go to
[preview.dune.build].

[here]
<https://ocaml.org/changelog/2025-05-19-portable-lock-directories-for-dune-package-management>

[preview.dune.build] <https://preview.dune.build/>

Semgrep is hiring OCaml developers to work on the static analysis engine
════════════════════════════════════════════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/job-remote-semgrep-is-hiring-ocaml-developers-to-work-on-the-static-analysis-engine/16771/1>

iago announced
──────────────

Semgrep is an application security company focused on detecting and
remediating vulnerabilities. The static analysis engine is primarily
written in OCaml. We are looking for a senior software engineer to
join the Code team, where we focus on first-party code vulnerability
and secrets scanning.

The ideal candidate has experience building program analysis tooling
or code scanners (perhaps in a research context).

Both on-site and remote work are OK.

If this sounds interesting to you, see our job posting at [Senior
Program Analysis Engineer, Code].

Let me know if you have any questions!

[Senior Program Analysis Engineer, Code]
<https://job-boards.greenhouse.io/semgrep/jobs/4752361007>

Elpe, a config-as-code build system written in OCaml+Rust
═════════════════════════════════════════════════════════

Archive:
<https://discuss.ocaml.org/t/elpe-a-config-as-code-build-system-written-in-ocaml-rust/16783/1>

pmeunier announced
──────────────────

I just released the first version of Elpe, a build system designed as
a blend of Nix and Ubuntu.

It uses OCaml for the frontend, and communicates with a Rust backend
via gRPC.

[Blog post about it]

[Blog post about it] <https://pijul.org/posts/2025-06-08-elpe>

Dune dev meeting
════════════════

Archive: <https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/31>

Etienne Marais announced
────────────────────────

Hello :vulcan_salute: The next Dune Dev Meeting will be tomorrow on
*Wednesday, June, 11th at 16:00 CEST*. This is going to be a
one-hour-long meeting.

Whether you are a maintainer, a regular contributor, a new joiner or
just curious, you are welcome to join: these discussions are opened!
The goal of these meetings is to provide a place to discuss the
ongoing work together and synchronize with the Dune developers :+1:

The agenda is available on the [meeting dedicated page]. Feel free to
add more items in it.

• Meeting link: [zoom]
• Calendar event: [google calendar]
• Wiki with information and previous notes: [dune wiki on GitHub]

[meeting dedicated page]
<https://github.com/ocaml/dune/wiki/dev-meeting-2025-06-11>

[zoom]
<https://us06web.zoom.us/j/85096877776?pwd=cWNhU1dHQ1ZNSjZuOUZCQ0h2by9Udz09>

[google calendar]
<https://calendar.google.com/calendar/u/0/embed?src=c_5cd698df6784e385b1cdcdc1dbca18c061faa96959a04781566d304dc9ec7319@group.calendar.google.com>

[dune wiki on GitHub] <https://github.com/ocaml/dune/wiki>

Other OCaml News
════════════════

From the ocaml.org blog
───────────────────────

Here are links from many OCaml blogs aggregated at [the ocaml.org
blog].

• [Opam Health Check: or How we Got to 90+% of Packages Building with
Dune Package Management]
• [Peer-Programming in Modern OCaml with ChatGPT and Gemini]
• [CEOS Project Kick-Off: Using Satellites to Survey the Earth]
• [Progress in OCaml docs]
• [The week that was - 2025 w21]
• [Build Meetup - Jane Street London]

[the ocaml.org blog] <https://ocaml.org/blog/>

[Opam Health Check: or How we Got to 90+% of Packages Building with Dune
Package Management]
<https://tarides.com/blog/2025-06-05-opam-health-check-or-how-we-got-to-90-of-packages-building-with-dune-package-management>

[Peer-Programming in Modern OCaml with ChatGPT and Gemini]
<https://soap.coffee/~lthms/posts/PeerProgrammingWithLLMs.html>

[CEOS Project Kick-Off: Using Satellites to Survey the Earth]
<https://tarides.com/blog/2025-05-30-ceos-project-kick-off-using-satellites-to-survey-the-earth>

[Progress in OCaml docs]
<https://jon.recoil.org/blog/2025/05/docs-progress.html>

[The week that was - 2025 w21]
<https://www.dra27.uk/blog/week-that-was/2025/05/24/wtw-21.html>

[Build Meetup - Jane Street London]
<https://www.dra27.uk/blog/misc/2025/05/23/build-event.html>

Old CWN
═══════

If you happen to miss a CWN, you can [send me a message] and I'll mail
it to you, or go take a look at [the archive] or the [RSS feed of the
archives].

If you also wish to receive it every week by mail, you may subscribe
to the [caml-list].

[Alan Schmitt]

[send me a message] <mailto:alan.schmitt@polytechnique.org>

[the archive] <https://alan.petitepomme.net/cwn/>

[RSS feed of the archives] <https://alan.petitepomme.net/cwn/cwn.rss>

[caml-list] <https://sympa.inria.fr/sympa/info/caml-list>

[Alan Schmitt] <https://alan.petitepomme.net/>

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