Why is building Ocaml projects still so hard?

Ecosystem
7

In my experience it’s usually a result of not locking down dependency versions properly. IMHO it’s a big problem in the opam ecosystem. And it seems likely here too.

The pinned commit version of ppx_jsobject_conv used by the example project: jsoo-react-realworld-example-app/jsoo-react-realworld-example.opam at main · jchavarri/jsoo-react-realworld-example-app · GitHub

pin-depends: [
  [ "jsoo-react.dev" "git+https://github.com/ml-in-barcelona/jsoo-react.git#9e86c9f" ]
  [ "ppx_jsobject_conv.dev" "git+https://github.com/little-arhat/ppx_jsobject_conv.git#b1c43be" ]
]

The unbounded version range of ppxlib (and other dependencies) used by ppx_jsobject_conv: ppx_jsobject_conv/ppx_jsobject_conv.opam at b1c43be251d8c7d39ee32ddc9968fdc3d0042c0b · little-arhat/ppx_jsobject_conv · GitHub

depends: [
  "ocaml" {>= "4.10.0"}
  "dune" {>= "2.7"}
  "js_of_ocaml" {>= "3.8.0"}
  "ppxlib" {>= "0.22.0"}
  "webtest" {with-test}
  "webtest-js" {with-test}
]

We can see that the Pext_decl constructor arity changes between different versions of the AST: Sign in to GitHub · GitHub

My bet is that some time between ppxlib.0.22.0 and ppxlib latest version, the default constructor arity changed from 2 to 3. And you can guess the rest.

This is why I insist on bounding my dependency version ranges, although in the case of 0.x.y i.e. projects which have not even reached their first major version, they can effectively make backwards incompatible changes even on a bugfix patch release.

1 Like