Camomile 2.0.0 is out and should be available in the opam repository.
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 no alternatives to convert from UTF-8 to outdated string encodings such as ISO-8859-1
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.
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!
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.
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?
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?)
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:
Compatibility patches
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.
no alternatives to convert from 