Hello Here is the latest OCaml Weekly News, for the week of April 28 to May 05, 2026. Table of Contents ───────────────── Oc — a Cargo-like CLI for OCaml beginners (AI-assisted, feedback very welcome) Dune Package Management Updates OCaml Users Survey 2026 OCaml Web tutorials Valkey 0.3.1: client-side caching, blocking pools, IAM auth and mTLS Old CWN Oc — a Cargo-like CLI for OCaml beginners (AI-assisted, feedback very welcome) ══════════════════════════════════════════════════════════════════════════════ Archive: Emil Kloeden announced ────────────────────── Hi everyone, I'm a newcomer to OCaml, and one of the things that has slowed me down is the tooling setup: understanding opam switches, remembering to `eval $(opam env)', knowing when to regenerate `.opam~files. So (together with Claude Code) I built ~oc' - a small CLI that wraps `opam' and `dune' and gives them a Cargo- or uv-like interface: ┌──── │ oc new my_app # scaffold project + initialise isolated switch │ oc add yojson # add dependency, update oc.toml, install │ oc build # ensure deps, dune build │ oc run # ensure deps, dune exec └──── No `opam switch create', no `eval $(opam env)', no hand-editing `.opam' files. What it is: ╌╌╌╌╌╌╌╌╌╌╌ A small, thin orchestration layer with no dependencies beyond opam and dune themselves. It calls opam to manage switches and resolve packages, and dune to build - wrapping the tools the community already uses and trusts rather than replacing them. It deliberately does less: if you want full control over your environment, opam gives you that directly. What it isn't: ╌╌╌╌╌╌╌╌╌╌╌╌╌╌ A replacement for opam or dune. The intention is to offer a simpler surface for those who prefer it, whether you're just starting out or you've been writing OCaml for years and want less ceremony for everyday tasks. A note on AI assistance: ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ I should be upfront: this project was developed almost entirely with the help of Claude Code. I wrote the specs, made the design decisions, and reviewed everything - but the code is almost entirely AI-generated. I think that's worth naming, both for transparency and because it's an interesting case study in what AI-assisted development looks like for a small tool. Prior art: ╌╌╌╌╌╌╌╌╌╌ I'm aware of a few similar efforts. `esy' is the closest in spirit - sandboxed builds, a lock file, a simpler manifest - but it makes some different choices: it requires Node.js (`npm install -g esy') and brings its own dependency resolver rather than delegating to opam. `oc' is a narrower tool: no additional runtime dependencies, stays on top of standard opam and dune, and trades power for simplicity.~ dune init project~ handles scaffolding but leaves switch management to you. opam's own local switches (`opam switch create . 5.2.0') are essentially what `oc' automates, but you still have to drive them manually. If there's something I've missed that already solves this cleanly, I'd genuinely like to know. Why not just shell aliases? ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ You probably could get close with a few shell functions. The reasons I went further: a cross-platform binary needs no shell setup, the lockfile gives reproducible builds across machines, and having a single `oc.toml' as the source of truth is cleaner than remembering which opam commands to run. Whether that's worth it is a fair question. Why Go, not OCaml: ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Partly the bootstrapping problem — it felt odd to write a tool that helps you set up OCaml before you can set up OCaml. More practically, Go made it easy to ship a single static binary with no runtime dependencies, and it let me build and iterate on the tool quickly. I'm not against a port to OCaml if someone wanted to take that on. Current state: ╌╌╌╌╌╌╌╌╌╌╌╌╌╌ The tool works for my personal use, has a test suite, a lockfile, and basic CI. It's rough around the edges and I'm sure there are things that would make an experienced OCaml developer wince. That's part of why I'm posting - I'd genuinely value feedback on: • Does this solve a real problem, or does the community have better answers I missed? • Are there correctness issues with how `oc' manages switches or generates `.opam' files? • What's missing before this would be useful to you? The homepage is at [emilkloeden.github.io/oc ] and the source is at [github.com/emilkloeden/oc]. Thanks for reading and I look forward to your feedback. [emilkloeden.github.io/oc ] [github.com/emilkloeden/oc] Dune Package Management Updates ═══════════════════════════════ Archive: Shon announced ────────────── Hello! The Tarides team is writing to share updates on Dune package management. Context ╌╌╌╌╌╌╌ Dune package management aims to improve some developer workflows by simplifying the use of opam dependencies in projects built with Dune. To learn more, see the tutorial, [OCaml Package Management With Dune]. It’s been too long since we shared an update, especially considering our gratitude for [all the excellent feedback] we have received. But Dune contributors have been hard at work [fixing issues] and solving tricky architectural snags present in the previous iteration. [OCaml Package Management With Dune] [all the excellent feedback] [fixing issues] Available now ╌╌╌╌╌╌╌╌╌╌╌╌╌ Thanks to many contributors, the following functionalities are available on Linux and MacOS in the latest release of Dune (3.22): • [managing dependencies published in opam repositories] (the [vast majority of opam packages are supported], but not all) • [pinning dependencies (recursively)] • [support for custom opam-repositories] (which, for example, can be used for OxCaml projects by following this [documented configuration recipe]) • [locking dependency versions], to provide a reproducible environment for developers and CI (portably, across supported platforms) • [support for managing select developer tooling] (shaky, but usable on the happy path) • most recently, we’ve [added support] for the [relocatable compiler] Additionally, the following supporting utilities are available: • [a binary distribution for supported platforms] offering nightly builds and released versions • [setup-dune], a GitHub action enabling quick and easy CI for projects that use dune package management [managing dependencies published in opam repositories] [vast majority of opam packages are supported] [pinning dependencies (recursively)] [support for custom opam-repositories] [documented configuration recipe] [locking dependency versions] [support for managing select developer tooling] [added support] [relocatable compiler] [a binary distribution for supported platforms] [setup-dune] Current status and focus ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Thanks to several regular users in the community and usage in many of the CI systems we maintain, we are gathering ongoing feedback and exercising the core functionality. However, our testing has shown the features are not yet mature enough to recommend wider use, beyond eager and early adopters. Consequently, all the documentation warns that this functionality is experimental and subject to change. We are currently focused on maturing package management beyond its experimental status. This requires reworking the developer tooling support, supporting packages that use symlinks, and ensuring we can dogfood Dune package management in its own development. The best place to look for what we have planned in this current phase is [Non-experimental package management · Milestone #62 · ocaml/dune]. [Non-experimental package management · Milestone #62 · ocaml/dune] Next up ╌╌╌╌╌╌╌╌ After maturing the core functionality, we will turn our focus to extending the supported platforms and improving ecosystem integration. This work will include adding support for Windows, improving cross-compilation, supporting advanced vendoring workflows, and integrating Dune package management into the *opam-ci*. More updates and more accessible planning will follow. Input and contributions ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Please [reach out] if you find this work interesting and would like to help! [reach out] OCaml Users Survey 2026 ═══════════════════════ Archive: Sabine Schmaltz announced ───────────────────────── Hi everyone, On behalf of the [OCaml Software Foundation] (OCSF), I'm delighted to announce the *OCaml Users Survey 2026*. We invite you to take 10 to 15 minutes to fill it out and to share it with other OCaml programmers. *Survey link:* The survey will remain open until *May 25th, 2026 (AOE)*. This year's edition builds on the [2023 iteration]. Many questions are kept comparable so we can track trends over time, while others have been refreshed, fixed, or added based on community feedback gathered earlier this year ([feedback thread]). Notable additions include questions on AI/LLM tooling and on debugging & profiling. A few notes: • The survey is administered via Google Forms but configured to *not* require signing in to a Google account, and answers are not tied to any account. As a consequence, your progress is *not* saved if you close your browser tab before finishing. • All questions are optional. • Please avoid entering personal information in free-form text fields: the raw responses will be made available to the community alongside the summary report. We will redact what we detect, but may miss some. • As an official OCaml online space, this survey has adopted the [OCaml Code of Conduct]. Results will be published on the OCSF website and announced here on discuss.ocaml.org. Thank you in advance for your participation, and please share the survey widely! – Sabine Schmaltz, on behalf of the OCaml Software Foundation [OCaml Software Foundation] [2023 iteration] [feedback thread] [OCaml Code of Conduct] OCaml Web tutorials ═══════════════════ Archive: Frédéric Loyer announced ──────────────────────── I have started a series of OCaml Web tutorials. The idea is to try multiple libraries and see how they fit together. (But the Dream framework document and example set is quite good enough, I will not paraphrase it). For the moment, I have only tried a Server Side Rendering, but I plan to try a Client Side Rendering where Ocsigen (and Vdom ?…) could be welcomed. The idea is to propose a dummy application that use what most people would expect from a Web Framework (form handling, database accesses, …) See [OCam web tutorials] [OCam web tutorials] Calascibetta Romain then suggested ────────────────────────────────── You can take an inspiration from the tutorial we made about [`vif'], it shows you websocket stuffs at the end and include `caqti' and `tyxml' :slight_smile: [`vif'] Valkey 0.3.1: client-side caching, blocking pools, IAM auth and mTLS ════════════════════════════════════════════════════════════════════ Archive: Avi Fenesh announced ──────────────────── Hi everyone, I wanted to share that `valkey.0.3.1' is now on opam. This is the next release after the `0.2.0' announcement. The short version: a few of the roadmap items from that post are now shipped — client-side caching, blocking-command pools, IAM auth, and mTLS. ┌──── │ opam update │ opam install valkey eio_main └──── Repo and docs: The largest new feature is *client-side caching*. `valkey' now supports Valkey `CLIENT TRACKING' with a bounded in-process LRU cache, RESP3 invalidation push handling, single-flight protection, optional TTL safety net, and metrics. It works in both standalone and cluster mode, and supports the three tracking shapes I wanted to cover: • default tracking • `BCAST' prefix tracking • `OPTIN' tracking The cluster path was the tricky part. OPTIN reads need `CLIENT CACHING YES' to stay adjacent to the actual read on the wire, including across MOVED / ASK redirects. That is now handled inside the client rather than pushed onto callers. The second big addition is a *blocking-command pool*. The normal client is still built around multiplexed connections, which is the right shape for regular traffic. But commands such as `BLPOP', `BRPOP', `BLMOVE', `BLMPOP', `BZPOP*', `XREAD BLOCK', and `XREADGROUP BLOCK' are intentionally blocking on the server side. Sending one of those through the normal multiplexed FIFO can freeze unrelated requests queued behind it. `0.3.x' adds a narrow per-node lease pool for those commands. Blocking calls lease an exclusive connection for the duration of the command, while regular traffic continues on the normal client. The pool is bounded, has typed errors, handles topology changes, and is off by default unless configured. The third addition is *IAM auth and mTLS*. There is now a first-class `Connection.Auth.provider' abstraction instead of only static username/password config. That means every initial handshake and reconnect can pull fresh credentials from a provider. On top of that, the library now includes: • pure OCaml AWS SigV4 signing for ElastiCache IAM auth • an auto-refreshing IAM provider • `Client.connect_with_iam' • live `AUTH' refresh support • mTLS client certificate configuration via `Tls_config.with_client_cert' The IAM path does not depend on the AWS SDK. The signer is implemented in OCaml and tested against AWS SigV4 test vectors. There were also a few correctness and operability improvements: • OpenTelemetry spans for connect, cluster discovery, and topology refresh • cache and blocking-pool metric bridges • tighter TLS / connection error redaction • better MOVED / ASK / topology-refresh behavior under cluster changes • fixes around WATCH / MULTI / EXEC when slot ownership changes during an atomic flow • more tests around CSC invalidation, cluster migration, blocking-pool behavior, IAM refresh, and mTLS config `0.3.1' itself is a small follow-up to make the opam sandbox tests clean: the mTLS config tests now use committed test fixtures instead of depending on generated certs from the local development scripts. The project is still alpha, and the API may still change before `1.0', but the surface is getting closer to the shape I originally wanted: an OCaml 5 / Eio-native Valkey client that treats cluster behavior, RESP3, modern Valkey features, and production failure modes as first-class concerns. I would especially appreciate feedback from people who use OCaml in production on: • API shape and naming • Eio ergonomics • docs clarity • whether the caching / blocking-pool / IAM APIs feel natural • what should be prioritized before `1.0' Next things on the roadmap are still Valkey module support — JSON, search, bloom — and a deeper pre-`1.0' audit pass. If you try it, I’d love to hear what feels good, what feels awkward, and what is missing. 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] [the archive] [RSS feed of the archives] [caml-list] [Alan Schmitt]