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

[Alan Schmitt <alan.schmitt@polytechnique.org>]

[-- Attachment #1.1.1: Type: text/plain, Size: 19632 bytes --]

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:
  <https://discuss.ocaml.org/t/oc-a-cargo-like-cli-for-ocaml-beginners-ai-assisted-feedback-very-welcome/18020/1>


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 ] <https://emilkloeden.github.io/oc>

[github.com/emilkloeden/oc] <https://github.com/emilkloeden/oc>


Dune Package Management Updates
═══════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/dune-package-management-updates/18023/1>


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]
<https://dune.readthedocs.io/en/stable/tutorials/dune-package-management/index.html>

[all the excellent feedback]
<https://github.com/ocaml/dune/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22package%20management%22>

[fixing issues]
<https://github.com/ocaml/dune/pulls?q=is%3Apr+pkg+is%3Aclosed>


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]
<https://dune.readthedocs.io/en/stable/tutorials/dune-package-management/setup.html#declare-dependencies>

[vast majority of opam packages are supported]
<https://dune.check.ci.dev/>

[pinning dependencies (recursively)]
<https://dune.readthedocs.io/en/stable/tutorials/dune-package-management/pinning.html>

[support for custom opam-repositories]
<https://dune.readthedocs.io/en/stable/tutorials/dune-package-management/repos.html>

[documented configuration recipe]
<https://dune.readthedocs.io/en/stable/tutorials/dune-package-management/oxcaml.html>

[locking dependency versions]
<https://dune.readthedocs.io/en/latest/tutorials/dune-package-management/locking.html>

[support for managing select developer tooling]
<https://dune.readthedocs.io/en/latest/reference/dune-tools.html>

[added support] <https://github.com/ocaml/dune/pull/13321>

[relocatable compiler]
<https://www.dra27.uk/blog/platform/2025/12/17/its-merged.html>

[a binary distribution for supported platforms]
<https://nightly.dune.build/>

[setup-dune] <https://github.com/ocaml-dune/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]
<https://github.com/ocaml/dune/milestone/62>


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] <https://github.com/ocaml/dune/blob/main/CONTRIBUTING.md>


OCaml Users Survey 2026
═══════════════════════

  Archive:
  <https://discuss.ocaml.org/t/ann-ocaml-users-survey-2026/18026/1>


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:* <https://forms.gle/gt5nikqUmoQWeYYQ9>

  <https://forms.gle/gt5nikqUmoQWeYYQ9>

  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] <https://ocaml-sf.org/>

[2023 iteration]
<https://discuss.ocaml.org/t/ann-ocaml-user-survey-2023/13469>

[feedback thread]
<https://discuss.ocaml.org/t/feedback-wanted-upcoming-ocaml-users-survey-2026-questions/17925>

[OCaml Code of Conduct] <https://ocaml.org/policies/code-of-conduct>


OCaml Web tutorials
═══════════════════

  Archive: <https://discuss.ocaml.org/t/ocaml-web-tutorials/18039/1>


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] <http://github.com/F-Loyer/OCaml_Web_tuto>


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'] <https://robur-coop.github.io/vif/>


Valkey 0.3.1: client-side caching, blocking pools, IAM auth and mTLS
════════════════════════════════════════════════════════════════════

  Archive:
  <https://discuss.ocaml.org/t/valkey-0-3-1-client-side-caching-blocking-pools-iam-auth-and-mtls/18041/1>


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: <https://github.com/avifenesh/ocaml-valkey>

  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] <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 #1.1.2: Type: text/html, Size: 31120 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 568 bytes --]