Opam packages: be honest with your dependencies

On paper (implicit_transitive_deps false) is an amazing feature.
However, in the current state it has a big downside: type aliases defined in transitive dependencies become abstract types.

In practice, it means that if I have library a defining:

type t = int result

a library b defining a simple function

val f : unit -> A.t

now, in my project to be able to do:

match B.f () with
| Ok 0 -> ...
| _ -> ...

I am now forced to explicitly depend on a too but a is never used explicitly and if the b library stops using it at some point i have [*] no other choice but to keep this dependency, monitor closely (pain) the library and drop the dependency when b does it too.

A few months ago on Slack I asked around if adding a new -implicit-include parameter to ocamlc could be considered and if I remember correctly there was a bit of a push-back against it from people saying it could be a linter phase in dune instead, but also some other people who were saying “a PR would be welcome”, but I didn’t have the time nor motivation to do it (I could reconsider if someone else wants to collaborate)

[*]: or worse i want to support several versions of this package using several different, sometimes incompatible, libraries.

1 Like