This is a headsup about some major package reorganisation for some MirageOS packages that are used by other projects as well. The Cohttp, Conduit, Dns, TCP/IP libraries have all been repackaged to do three things:

What has improved

Removed optional dependencies from the opam packaging that would activate the compilation of features. While this was a good idea in the early days of opam, it now leads to having to specify a long set of packages to make a particular backend available (e.g. for dns.lwt). In MirageOS, we are moving towards explicit opam packages for extra functionality, and deprecating the use of depopts where possible.

Ported to Jbuilder to speed up builds, and use modern OCaml features. This means that the use of pack is gone in TCP/IP in favour of module aliases, and that build times have sped up by roughly 4-5x for many of the libraries and applications using them. They are also more easily embeddable in third-party projects using the Jbuilder workspace support.

Camlp4 entirely eliminated, ppx_driver now used: the move away from camlp4 is now complete (we even have a no-camlp4 package to warn if it returns to our dependency chain). The modern use of ppx enforces the use of ocaml migrate-parsetree so that they can be built in the latest releases of OCaml more easily as well.

What is incompatible

The primary change you will observe is that an ocamlfind package that was formerly in the subpackage format (e.g. cohttp.lwt ) is now using a dashed format and is a separate opam package (e.g. cohttp-lwt ). This requires you to port your libraries to adjust the build to:

set a minimum opam constraint on the version of library to >="0.99" to exclude older releases.

to exclude older releases. add an opam dependency on the feature required (e.g. cohttp-lwt-unix )

) adjust the ocamlfind dependencies to replace dots with dashes (e.g. cohttp.lwt -> cohttp-lwt ).

-> ). release a new version of the package to the stable opam-repository

Here is the table of old/new opam packages and old/new ocamlfind packages, along with the opam version constraint for the new opam package.

old opam packages new opam package old ocamlfind new ocamlfind conduit conduit >=1.0.0 conduit conduit conduit lwt lwt_ssl conduit-lwt >=1.0.0 conduit-lwt conduit-lwt conduit mirage-types-lwt mirage-flow-lwt dns [and more...] mirage-conduit >=3.0.0 conduit.mirage mirage-conduit conduit async async_ssl conduit-async >=1.0.0 conduit.async conduit-async old opam packages new opam package old ocamlfind new ocamlfind cohttp cohttp >=1.0.0 cohttp cohttp cohttp lwt cohttp-lwt >=1.0.0 cohttp.lwt-core cohttp-lwt cohttp lwt base-unix cohttp-lwt-unix >=1.0.0 cohttp.lwt cohttp-lwt-unix cohttp js_of_ocaml cohttp-lwt-jsoo >=1.0.0 cohttp.js cohttp-lwt-jsoo cohttp async cohttp-async >=1.0.0 cohttp.async cohttp-async cohttp mirage-http mirage-http >=3.2.0 cohttp.mirage mirage-http tcpip tcpip tcpip >=3.2.0 tcpip old opam packages new opam package old ocamlfind new ocamlfind dns dns >=1.0.0 dns dns dns lwt mirage-profile cmdliner dns-lwt >=1.0.0 dns.lwt-core dns-lwt dns lwt mirage-profile cmdliner dns-lwt-unix >=1.0.0 dns.lwt dns-lwt-unix dns mirage-time-lwt mirage-stack-lwt mirage-kv-lwt lwt duration mirage-profile mirage-dns >=3.0.0 dns.mirage mirage-dns dns async dns-async >=1.0.0 dns.async dns-async

Where the work is

cohttp #558 : the 1.0 release plan

opam-repository #9824 : the opam repository pull request with the new packages

There have also been around 30 or 40 upper bounds added to existing users of Cohttp. We would really appreciate your help with updating your own code to the newer version so that users aren’t held back by these constraints. Please reply to this post with any questions or difficulties you have with moving to the newest version of Cohttp.

We also realise how confusing the old package structure was, as it grew very fast out of an initially simple set of clean-slate network protocol implementations for the MirageOS project. We are now steadily working on restructuring the repositories to make them easier to use and integrate your feature additions, so thanks for all the patience so far

Many thanks to @rgrinberg @samoht and @djs55 who did a vast amount of work to make this particular restructuring possible, and the many other contributors who are noted in the changelogs of the libraries.