Hello PPX users (directly or transitively),
I’d like to discuss here in this thread if there’s still a demand to use ppxlib and ocaml-migrate-parsetree.1.x (OMP1) in the same project. Yesterday, I posted here on discuss about the state of the PPX ecosystem and pointed out that the public PPX ecosystem has almost completely shifted to ppxlib. Still, we’d like to know your perspective on this question. Have you lately run into a problem due to the incompatibility between ppxlib and OMP1? Did you formerly have such problems but lately all the PPXs you use have already been ported to ppxlib? These questions are directed to any OCaml user, so please comment any details on this post and point out which PPXs were involved. Thanks in advance!
The rest of this post gives some more context about why we’re asking these questions now in case folks are interested, but it’s not needed for the discussion we’d like to have about the questions stated above.
Some Context
The next ppxlib release 0.23.0 will contain the integration of Astlib and therefore will drop its dependency on ocaml-migrate-parsetree (OMP). Now we need to decide if to mark OMP1 as a conflict for ppxlib in opam or not.
To give more background, the PPX ecosystem is transitioning to be more up-to-date. The three contextually relevant states of this transition are:
-
ppxlibdepends onOMP < 2.0.0. The PPX driver is inOMP. -
ppxlibdepends onOMP >= 2.0.0. The PPX driver is inppxlib. -
ppxlibdoesn’t depend onOMPanymore. It uses its internal / the compiler libraryAstlib.
The PPX driver is inppxlib.
During State 1, you can use ppxlib PPXs and OMP1 PPXs in the same project. During State 2, ppxlib opam conflicts with OMP1. During State 3, if we leave everything as-is, you can install both ppxlib and OMP1 for the same project. But also during State 3, you’re unable to use ppxlib PPXs and OMP1 PPXs in the same library or executable because if your build system uses a PPX driver, the PPX driver needs to be unique. Now we need to decide whether to leave the conflict between ppxlib of State 3 and OMP1 at the level of the build system or to lift it up to the package manager by making OMP1 an opam conflict for ppxlib. Both options have their pros and cons, which have already been somewhat discussed on the corresponding PR. To sum them up:
Option 1: not making OMP1 a conflict for ppxlib
Advantage: You would be able to use ppxlib PPXs and OMP1 PPXs in the same project, but they still can’t be used together inside the same library or executable.
Disadvantage: If you use several PPXs inside the same library or executable, there’s no direct guarantee that you and your users install compatible versions of the PPXs for the build system. To guarantee that, you’d have to add certain dependency constraints to your opam file. We would make sure the way to define those dependency constraints would be well documented and could be found easily.
Option 2: making OMP1 a conflict for ppxlib
Advantage: Without adding any dependency constraints yourself, opam will ensure that you and your users don’t install both ppxlib and OMP1, only to get an error at build time.
Disadvantage: You couldn’t use ppxlib PPXs and OMP1 PPXs in the same project, not even separating them at the level of libraries/executables. You also couldn’t use an exectubale based on ppxlib together with a OMP1 PPX in the same project. In short: the situation would stay the same as it is currently during State 2.
To make the best decision, we need to know if the possibility to use ppxlib and OMP1 inside the same project, separated by libraries/executables, is still in demand.
