search

ocurrent / ocaml-ci

A CI for OCaml projects
https://ocaml.ci.dev
MIT License
112 stars 74 forks source link

Only build co-installable packages on supported compilers #470

Open tmcgilchrist opened 2 years ago

tmcgilchrist commented 2 years ago

LWT project encountered an interesting corner case that will become more common as packages add support for OCaml 5.0 features while still supporting OCaml 4.* versions.

The LWT repository [https://github.com/ocsigen/lwt] consists of 6 packages: lwt, lwt_luv, lwt_ppx, lwt_ppx_let, lwt_react and lwt_domains. Everything except lwt_domains should work with a range of OCaml versions from 4.08 onwards, while lwt_domains is only supported on OCaml compilers with the domains multcore support (currentl 4.12+domains and the soon to be released 5.0). See this https://github.com/ocsigen/lwt/pull/947

Before PR#468 ocaml-ci would only find a single supported compiler variant to build against, 4.12+domains, since that is the only variant that satisfies all the packages together. In fact lwt_domains implies this.

After PR#468 ocaml-ci finds many compiler versions and tries building on 4.02 -> 4.14. However the build fails on lwt_domains on most of those because of missing domains support. alpine-3.14-4.14 (failed: Library "lwt_domain" not found) https://ci.ocamllabs.io/github/tmcgilchrist/lwt/commit/e59681a87a440852ca4d42b46422fe6bdcee64ee/variant/(analysis)

ocaml-ci should work out a selection of packages that are co-installable per ocaml variant, rather than needing all of them to be installable.

Related to https://github.com/ocurrent/ocaml-ci/pull/468

talex5 commented 2 years ago

In general this is a hard problem. For example, consider a repository with two packages that conflict with each other. So #468 takes the simpler solution of requiring the opam file to be explicit about whether it is expected to work on multicore or not.

We might also want to go further and say that if e.g. a package specifies "ocaml >= 4.03" then it must be installable on 4.03. However, this is less useful at the other end: "ocaml >= 4.03" probably shouldn't require it to be installable on 5.0+trunk, because that's likely to be a temporary problem while its dependencies are being updated.

gridbugs commented 2 years ago

I currently have a use case relevant to this issue. I'm working on a benchmark runner for ppxlib, and the runner has additional dependencies to ppxlib so I've made a separate package "ppxlib-bench" (in the same repo) to prevent adding unnecessary deps to ppxlib. One of these deps requires a version of the ocaml compiler that is more recent than the oldest version supported by ppxlib. This means that when ci runs on the ppxlib repository, it only tests with versions of the compiler compatible with ppxlib-bench, but I would like for ppxlib to still be tested on the older versions of the compiler. I could fix this by moving ppxlib-bench to a separate repo but it would be convenient to keep it as part of the ppxlib repo.

raphael-proust commented 1 year ago

FWIW, the inconsistencies in ocaml version support is the reason why we moved lwt_domain out of the main repo and into its own: https://github.com/ocsigen/lwt_domain. I haven't yet removed the package from the lwt repository (that's an omission on my part).

It's still worth supporting these kinds of multi-packages repo though.