[ANN] Camomile 2.0.0 is out!

Hi all!

Camomile 2.0.0 is out and should be available in the opam repository. :tada:

This releases brings compatibility with OCaml 5 to camomile and all projects using it as well as a cleanup of the API and build system.

We have used camomile for years with liquidsoap and, after OCaml 5 came out, the library was not building with it and appeared unmaintained. However, after looking for alternatives, it appeared that there were :warning: no alternatives to convert from UTF-8 to outdated string encodings such as ISO-8859-1 :warning:

While there are modules that allow to do the opposite, we believe that, in order to be successful and widespread, the OCaml ecosystem needs to be able to accommodate to legacy computer systems and protocols and, in particular, be able to output strings to legacy string encodings so we decided to see about bringing camomile up-to speed with the latest OCaml compiler and tooling.

The fork is currently located at GitHub - savonet/Camomile: A Unicode library for OCaml and was approved by the original author yoriyuki. We are immensely grateful for his work up-to this point.

Make no mistake, though: the module is still in dire need of maintainers. Ideally, we would like to move the module to ocaml-community and bring more people onboard to help with it.

To reflect back to the last actual release, things that should be worked on next are are least:

  • split the module into several libraries, so that a user do not need to install the entire (several megabytes) libraries
  • support latest Unicode standard (it is very outdated)

If you are interested in helping with it, please feel free to contact us or send some PRs our way!


This is a historic event, good to see a release!


Thank you for your efforts maintaining this and putting out a new release.

I would also like to see it maintained in a community organisation like ocaml-community. However it seems like that organisation is not very active or difficult to contribute to. @Drup is it possible to get some clarification around Process for moving projects to ocaml-community · Issue #11 · ocaml-community/meta · GitHub and how new maintainers might be added to the org.


For what it’s worth, for doing that specific transformation there’s also a combination of Uutf and Uunf to achieve this, which I made myself a little wrapper for. For the other way around, I’m using stdlib’s Uchar.of_char |> Buffer.add_utf_8_uchar without dependencies since I need Unicode Normal Form C anyway.

Of course that’s not useful for any other encoding; I just got lucky. :wink:

Folks, I’m all for it, but the way you made this release will not make any other camomile users happy — it will drive them mad as hell. As a camomile user, I’m certainly mad now.

You changed the public API in an incompatible way. I believe you that the change is well-intentioned but put yourself in a reverse dependency maintainer shoes: I now have to adapt my code to your new release, and I need to know how to do it. First thing I do is go read the release notes, and all I see is… “Cleanup public API”.

Maybe there’s now a link to generated docs? Maybe there’s an updated usage example in the README at least? Nope. N o p e! There were none, there are still none.

Maybe I can explore the API from the REPL, if nothing else? Fat chance! Even that is no longer simple.

utop # #require "camomile";;
Error: Reference to undefined global `Dune_site__Dune_site_data'

(That’s with OCaml 4.14, dune 3.7.0; the error comes from loading dune-site.plugins — I only figured out that much so far).

I will go read the source because that’s all I can do, but did you really expect people to take this kind of maintenance practices kindly? I certainly wouldn’t.

Just curious: aren’t those API breaking changes specific to version 2.0.0? Couldn’t existing projects depending on it just specify their need for 1.x instead of adapting to 2.x?


Sorry for the frustration. The API was never documented well either appart from the top-level module. You can read it here: Camomile/camomile.ml at main · savonet/Camomile · GitHub

The API changes are simple, really. If you were using Camomile.CamomileDefaultLibrary, now you can use Camomile.

If you were using any of the modules or functor from Camomile.CamomileLibrary, now you can use Camomile as well.

I’m not sure about the dune-site error. I have seen it as well and will forward it to the maintainer.

Also, as the original post was saying, we are still in dire need of maintainers. If you want to contribute to examples and documentations, that would be greatly appreciated!

I’m happy to help. This could also be communicated, though. Are you against usage examples in the README, for example, or a PR to add one is a good idea?

If you want an unsolicited opinion, when there’s a shortage of maintainer time, it’s usually better to release urgent changes quickly (like the OCaml 5.0.0 compatibility part) and wait with bigger changes. Announcing a fork, new maintainer team, and 5.0.0 compatibility here could draw new contributors in before the release (e.g. me). The problem with REPL loading could be figured out and fixed or documented before it became the last straw for writing a rant for the first existing user who attempted a dependency update. You have me on board at least for small improvements when my time allows, but it all could be better if the release wasn’t rushed.

@VPhantom Well, of course it’s always an option but not a sustainable one. Sooner or later it will lead to unsatisfiable dependency graphs at least for some users and I’d like to avoid it whenever I can.


I get the desire to simplify the API, and remove unnecessary cruft so that new users have an easier time understanding the module.
However for the benefit of the ~1006 reverse dependencies of the package (when considering reverse dependencies recursively) compatibility could’ve been retained, e.g. by providing a ‘camomile.library’ ocamlfind package that provides the old module names as aliases for the new one (perhaps part of an camomile-compat opam package, and then the direct reverse dependencies of camomile could be updated to temporarily depend on camomile-compat until they’re updated to 2.0?)

1 Like

Any chance you could try this branch and confirm if the camomile-compat module works for you: Add compat module. by toots · Pull Request #4 · savonet/Camomile · GitHub ?

I understand your concerns and am looking forward to working with you on improving this.

I would be interested in helping maintain this project, however I think the top priority should be writing a migration guide for all the users of Camomile 1.0.2 and package maintainers.

I agree with a lot of the criticism above which essentially comes down to mixing these two steps:

  1. Compatibility patches
  2. Cleaning up the API

The issue is that there are a lot of dependencies of Camomile and not everybody wants to spend time looking into an undocumented API just to get their library compatible.

Therefore we need to make a guide, that almost anybody can follow, to switch from Camomile 1.0.2 to 2.0.0.

The best way to write such a document is while attempting to migrate other libraries to use Camomile 2.0.0. That way we will see what common API changes need to be written down.

In case not everyone is aware, the CI system for opam runs a reverse dependencies check when a PR is submitted. The one for Camomile 2.0 is here. It might help with tracking down what things are broken by this release.

Yes. In opam world, nothing is broken at the moment as all modules depending on camomile have been marked as requiring the old API.

We are working on a compat module that should allow a quick drop-in replacement to migrate existing code.

Meanwhile, the new API should also be fairly easy to use.

1 Like