OCaml Weekly News

Note that some of the new features of this release are only accessible through the still unstable caqti.template library, which will soon be stabilized as part of an upcoming Caqti 3 API. Due to adjustments to module names, switching to caqti.template will not ensure future compatibility. Instead, users are encouraged to add the new caqti.classic to their dependencies to ease migration to Caqti 3.

• Added an alias caqti.classic for the caqti library. This will be turned into a library providing compatibility with the current Caqti 2 API when Caqti 3 is released. The two APIs can be used side-by-side to allow incremental migration.
• The dialect descriptor for MariaDB in caqti.template now provides the server version.
• Added Query.parens, Query.litf, Query.vars, Row_type.fields to the caqti.template library.
• Revised the interface for creating row types to allow instantiating parametric types applicatively. Before this change, each application of a function representing a parametric type would generate a new type ID even when applied to the same type parameter argument. The key part of this interface is the Caqti_template.Constructor_type module.
• The query functions provided to request templates are now memoized, so that they are only called once per dialect. This is meant as an optimization; it's still good practise to avoid side-effects here.
• The new function Query.with_pos_of allows query generators to add source locations to the syntax tree, which will be emitted as SQL comments in the query string if the enable_query_annotations is set. This should simplify debugging when the query is assembled from different parts of the application code.
• The still unstable caqti.template library now supports multiple statements in a single request template, sent opportunistically as a single query where allowed. This is still experimental.
• Fixed package scoping of shim rules for sqlite3 (#133 by mefyl).
• Fixed the error classification for the SQLite3 driver (#132).
• Fixed reconnect after connection loss for PostgreSQL.

• Revert the change in behavior of --diff-command back to 3.21. Non-existent files are now passed to this command instead of being replaced with /dev/null (#14098, fixes 13891, @rgrinberg)

Our first experiments already showed that we could handle emails with MirageOS unikernels. But we also hit real limitations: memory leaks, security vulnerabilities, and build issues.

So we decided to start fresh, and take the opportunity to fully embrace OCaml 5 and effects. We rebuilt the key pieces from scratch:

• a new effect-based scheduler: Miou/Mkernel
• a much more complete TCP/IP stack: Mnet
• a new FAT32 file system: Mfat

ptt is built on this new stack, and so far we haven’t observed any memory leaks (thanks to mkernel-memtrace for tracing memory usage, viewable via memtrace-viewer). The CVEs related to mirage-tcpip were taken into account during ~mnet~’s development, and the build story is much simpler now. A GitHub action can build and actually run the unikernel to test it, as you can see with mnet.

Other unikernels using this approach are available too. If you’re curious, check out this tutorial on creating a unikernel in OCaml.

ptt also tackles the deployment question. We have an article presenting the "stateless" aspect of ptt. We'd also like to (re)introduce [Albatross](github.com/robur-coop/albatross), our secure unikernel orchestrator, and Mollymawk, a web interface for deploying unikernels (which is itself a unikernel).

More broadly, this is what our cooperative is working towards: we really want to improve the user experience, whether you're a developer or a deployer. We believe that actually developing, deploying, and using our unikernels is the only way to get them adopted more widely. So make sure to follow us on these projects too!

Along the way, we found it really helpful to have a tool that lets you track every stage of an email’s lifecycle. That’s how blaze came about: a Swiss Army knife for handling emails.

It’s still experimental, but it already lets you:

• use our archive system (generate, read, index, etc.)
• handle other archives such as mbox or maildir
• communicate via the POP3 protocol
• sign and verify emails (DKIM and ARC)
• build emails from the command line
• send emails
• run a small local SMTP server

blaze is how we iterate on our library APIs and validate implementations. It’s experimental, but it’s gradually turning into a full email client.

Thanks to all this work, OCaml now has a solid set of email-related projects. This journey started back in 2016 and there's still a long way to go, as we always aim to offer robu(r)st, battle-tested solutions. Unlike some implementations in other languages (though we are in discussion with folks in the Rust community), ours actually adhere to the standards!

It may not seem like a big deal, and you won't see any major difference when just exchanging emails, but we believe this approach paves the way for a better internet. In the form of unikernels, it represents a genuine reclaiming of the means of communication!

The upgrade instructions are unchanged:

For Unix systems

bash -c "sh <(curl -fsSL https://opam.ocaml.org/install.sh) –version 2.5.1"

or from PowerShell for Windows systems

Invoke-Expression "& { $(Invoke-RestMethod https://opam.ocaml.org/install.ps1) } -Version 2.5.1"

Please report any issues to the bug-tracker.

Happy hacking,

<> <> The opam team <> <> :camel:

We've already kicked off a couple of initiatives:

• OCaml Weekly News - Japanese Edition: We're maintaining a Japanese translation of the OCaml Weekly News at https://ocaml.jp/cwn-ja/, making it easier for Japanese speakers to stay up to date with the latest happenings in the OCaml ecosystem.
• OCaml Meetup in Tokyo (August 2026): We are currently preparing to host an OCaml Meetup in Tokyo this August, the first one in over ten years! More details will be shared soon; please stay tuned!

We're using Discord as our primary communication platforms. Whether you're based in Japan, are a Japanese-speaking OCaml enthusiast anywhere in the world, or simply want to connect with the Japanese OCaml community, we'd love to have you join us!

Please use the following link to join Discord: https://discord.gg/qQTbny8KF4

We look forward to building a vibrant OCaml community in Japan together. よろしくお願いします！

In the upcoming release, one can also write

module type M = [%mixins Map.OrderedType + Printable]
(* desugars to *)
module type M = sig 
   type t 
   include Map.OrderedType with type t := t
   include Printable with type t := t
end

One can also override other types, e.g.

type u [@@mixins Mappable(key = int; value := v)]
(* desugars to *)
type u
include Mappable with type t := u and type key = int and type value := v

• No support for parametric types, e.g. with type 'a u = 'a v
• No support for tuple and function types, e.g. with type t = int -> bool

This is because the preprocessor parses the payload as an expression, and these don't parse nicely a expressions. Deeper support (e.g. for mixins with type parameters) would probably also require language support.

When libA depends on libB, Dune gives every module in libA a glob dependency on all .cmi files in libB. If any .cmi in libB changes, every module in libA is recompiled — even modules that never reference libB.

For projects with many libraries, this creates a cascade of unnecessary recompilations. The issue that tracks this matter #4572 has been open since 2021.

Dune already runs ocamldep to compute intra-library module dependencies. The key insight: that same output tells us which libraries each module references, via their entry module names. We can use this to filter both the build dependencies and the -I~/-H~ compiler flags per-module.

The implementation (PR #14116 and PR #14186) works as follows:

1. For each module and its transitive intra-library dependencies, read the ocamldep output (both .ml and .mli)
2. Union all referenced module names, including -open flags
3. Map those names to libraries via a Lib_index
4. Transitively close the filtered library set via Lib.closure
5. Use the result for both hidden deps and -I~/-H~ compiler flags, partitioning into direct (visible via -I) and hidden (via -H) based on requires_compile membership

With both deps and flags filtered, a clean build will fail if a module references a library it doesn't declare — previously, overly-broad -I flags could mask such errors.

My first attempt (PR #14021) tried to implement the filtering in a single PR without sufficient test coverage. It was closed after review revealed that the approach was fragile in edge cases I hadn't anticipated — particularly around transparent module aliases and virtual libraries.

Transparent module aliases. OCaml's module alias mechanism means ocamldep doesn't always report all libraries a module transitively depends on. If libB has module M = LibC.Something, and a module in libA uses LibB.M, ocamldep reports LibB but not LibC. The fix: transitively close the filtered library set using Lib.closure, bounded by the compilation context.

Root modules. The (root_module) stanza creates a module that implicitly aliases all libraries in the compilation context. When ocamldep reports a reference to a root module, we can't determine which underlying libraries are actually needed, so we fall back to the full dependency set.

Virtual libraries. When virtual library implementations are present in the compilation context, parameter libraries may not appear in requires_compile, so filtering could miss them. Another fallback case.

Menhir-generated modules. These mock modules aren't in the ocamldep dependency graph, so we skip filtering for them.

Null build overhead. The filtering reads .d files and computes library closures per-module. On a fresh dune process (no memo cache), this is new work on every build — including null builds where nothing changed. This is a real trade-off: better incremental rebuild performance at the cost of some null-build overhead.

Before the implementation PRs, I submitted six test-only PRs to document existing behavior and establish a safety net:

• #14017 — Baseline tests documenting current inter-library recompilation behavior
• #14031 — Test documenting module name shadowing between stanzas and libraries
• #14100 — Test verifying library file deps in compilation rules and sandboxed builds
• #14101 — Test verifying transparent alias incremental build safety
• #14129 — Test verifying incremental builds with alias re-exported libraries
• #14178 — Test documenting ocamldep behavior with transparent alias chains

This made the implementation PRs' diffs focused on the actual change, and gave reviewers confidence that existing behavior was preserved. It also helped me understand the edge cases that tripped up my first attempt.

The Dune maintainers (@rgrinberg and @art-w) provided thorough, constructive reviews. Some highlights:

• Replacing my hand-rolled transitive closure with Lib.closure from the existing library — a cleaner approach I wouldn't have found without familiarity with Dune's internals
• Identifying that both .ml and .mli ocamldep output need to be read, since the interface can reference different libraries than the implementation
• Suggesting per-module -I~/-H~ flag filtering, which makes clean builds more precise and improves caching
• Questioning every fallback case and special-cased module kind, leading to simpler code

The PRs went through significant refactoring during review — the final versions are substantially tighter than the initial submissions.

Working on this was a positive experience overall, but a few things created friction:

No way to benchmark before merging. The null-build overhead question came up late in the process. I discovered through manual benchmarking that the change added \~70% to null build time — a significant regression. Dune's benchmark CI workflow runs only on pushes to main, not on PRs. Contributor-accessible performance tooling would help catch regressions before they land.

Review momentum vs. rebasing. The test PRs merged quickly, but the implementation PR required multiple rounds of review over days. Between rounds, main moves forward, requiring rebases that risk introducing conflicts. The contributor carries the burden of keeping branches fresh. This is compounded when PRs depend on each other — every rebase of #14116 required rebasing #14186 as well. GitHub has no first-class support for PR stacks, so this is manual and error-prone. Of course, all GitHub-hosted repos suffer from this.

Flaky CI. Many CI runs had errors that were not related to my code. It was often an upstream provider of an OCaml package that was unreachable or faulty (temporarily). These problems often resolved themselves, but caused day-long delays in the PR lifetimes. The problem stems from the setup code that is run and re-run over and over in CI jobs.

The Dune codebase is well-structured, with clear separation between the build engine, rule generation, and scheduler. It is also of good quality, making it feel like time spent on keeping the quality high is worthwhile.

I found the cram test infrastructure good for testing. Each test scenario is a self-contained shell script with expected output, making it easy to document and verify exact recompilation behavior. It inspires confidence in the code.

The maintainers have been responsive and the review process, while slowed by thoroughness, is collaborative and professional. Thank you, maintainers!

The base compiler can be installed as an opam switch with the following commands on opam 2.1 and later:

opam update
opam switch create 5.5.0~beta1

The source code for the beta is also available at these addresses:

• GitHub: https://github.com/ocaml/ocaml/archive/5.5.0-beta1.tar.gz
• OCaml archives at Inria: https://caml.inria.fr/pub/distrib/ocaml-5.5/ocaml-5.5.0~beta1.tar.gz

If you want to tweak the configuration of the compiler, you can switch to the option variant with:

opam update
opam switch create <switch_name> ocaml-variants.5.5.0~beta1+options <option_list>

where option_list is a space separated list of ocaml-option-* packages. For instance, for a flambda and no-flat-float-array switch:

opam switch create 5.5.0~beta1+flambda+nffa ocaml-variants.5.5.0~beta1+options ocaml-option-flambda ocaml-option-no-flat-float-array

All available options can be listed with opam search ocaml-option.