I maintain a package that uses a function in Core.Unix. It expects this:
val socket :
as of core v0.14, the interface was extended to this:
val socket :
My package won’t compile anymore. I need to throw a () onto the end of the
As a package maintainer I can do the easy thing, add the (), say it requires core >= v0.14, and everyone who isn’t ready to update has to learn about pinning packages.
That kinda sucks? IMO the ideal solution would be to conditionally compile based on what version of core is installed. If core >= v0.14, call socket with a trailing (). Otherwise leave it out.
Is there a way of portably achieving this conditional compilation with minimal cognitive/maintenance burden?
Maybe do the following:
- release a version of your package with the dependency rule “core_kernel < 0.14” (and no other changes)
- immediately after, release a version with the updates, and the dependency rule “core_kernel >= 0.14”
That way, users who continue to use core_kernel < 0.14 can continue to seamlessly install your package, and so can users with the newer core_kernel ?
I realize that this isn’t what you’re asking for. Of course, you could write your build-file to check the version of core_kernel, and use
cppo to conditionally-compile code. But this would be fragile and painful-to-test.
I -do- think that the “social process” of opam encourages people to think of the entire collection of opam packages as a “single repo” in the style of Google3. And that isn’t a bad thing.
Alternatively you can use cppo or ppx_optcomp to have conditional compilation of the function calls, but it gets messy over time with the evolution of your dependencies